Your site suddenly disappears after an update or a hack, or you want to switch to a different hosting provider—and only then do you wonder if your backup actually works. A WordPress backup is a complete copy of your database and files, which you can use to restore your site after an error or a hack. Migration is the process of transferring that copy to another server or domain. Without a working backup, migration isn’t safe. In this guide, I’ll explain exactly what a backup is, how to create, store, test, and restore it, and how to safely move your site afterward. For each topic, I’ll link to the article where we go into more detail.
Backup, export, migration, and cloning: What's the difference?
A backup is a complete copy of your site, database, and files at a specific point in time. An XML export is just your content in a text file. A migration is the process of moving your entire site to a different server or domain. A clone is a working copy of your site on the same hosting account, which you can use, for example, as a staging environment to test updates. In support inquiries, I regularly see these four terms used interchangeably, and that’s exactly where things go wrong.
| Concept | What's Inside | What is it for? | What It Is Not |
|---|---|---|---|
| Backup | Database and files as of a specific point in time | Recovery After an Error, Hack, or Failed Update | No protection against a leak that's still there |
| XML Export | Posts, pages, comments, and menus | Migrating Content to Another WordPress Site | No backup, because the theme, plugins, settings, and media files are missing |
| Migration | The entire site has been moved | Moving to a different hosting provider or a different domain | No copy is left behind—that's why you should back up first |
| Clone or staging environment | Working copy on the same hosting account | Testing Updates and Performing Recovery Tests | No backup, because it's on the same server |
Most of the confusion stems from the export function under Extras > Export. That sounds like a backup, but it isn't. You'll get an XML file containing your content, and without your theme, plugins, and settings, you can't restore a working site from it. You can read about what the export is actually good for in Exporting a WordPress Site Using the XML Export Feature. Instructions on how to create a test copy can be found in the staging environment.
What's included in a full WordPress backup?
A complete WordPress backup consists of two parts: the database and the files. The database contains your posts, pages, settings, and users, and—if you have an online store—your orders and customers as well. The files are mainly located in the folder wp-content, including your themes, plugins, and uploads such as images and PDFs. In addition, there are wp-config.php, containing the information WordPress uses to connect to the database, and .htaccess with your server rules.
Strictly speaking, you don’t need to include the WordPress core itself, since you can easily download it again. But it doesn’t hurt to include it. What does go wrong, however, is a backup that contains only the database or only the files. That’s a partial backup, and you can’t restore a complete site with a partial backup. It’s also important that both parts be from the same point in time. I call this a “backup set,” and that term will come up again later when we discuss restoration.
How to Back Up WordPress: Three Methods
You can back up your WordPress site through your hosting provider, using a backup plugin, or manually. My advice is to set up at least one automated backup method and also keep one copy outside of your hosting account. That way, you’ll have a real safety net—not just a false sense of security.
Through your hosting provider
Your hosting provider automatically creates a hosting backup, separate from your WordPress installation. That’s the approach I recommend to everyone as a baseline, because you can restore it even if WordPress itself stops loading. The downside is that everything is stored with the same provider if this is your only copy. Therefore, ask your host how often backups are created, how long they’re retained, and which data center they’re stored in. A good hosting provider will have specific answers to those three questions.
With a backup plugin
A backup plugin creates a copy of your WordPress site and, ideally, stores it in external cloud storage. Well-known examples include UpdraftPlus, Duplicator, and All-in-One WP Migration, and the features available for free vary by plugin. The strength lies in that external storage, because it gives you a copy outside your hosting environment. The weakness is that the plugin runs on the same server as your site. If the site goes down, the plugin won’t work either, and large sites often run into memory or file size limits.
Manual
Manual backup means that you download the files yourself via SFTP or the file manager and export the database via phpMyAdmin or using WP DB Export in WP-CLI. That's prone to errors and never happens automatically. I only do it as a one-time extra backup right before a major change, and I especially recommend it to developers.
How often and where do you store your backups?
How often you back up your site should depend on how often it changes. A low-traffic business site can get by with a weekly backup, an active site needs daily backups, and an online store actually needs them even more frequently. Regardless, you should always create an extra backup right before an update or migration. For storage, I follow the 3-2-1 rule, which states that you should have three copies on two different types of storage, one of which is outside your hosting provider. In addition, keep multiple restore points over a longer period—for example, daily, weekly, and monthly. After all, you often don’t discover a hack until weeks later, and by then you’ll want to be able to go back far enough. Also, check every now and then to make sure your automatic backups are actually running. More on this in how often you back up your data and the 3-2-1 rule.
What is often forgotten is that backup files contain sensitive data. They contain wp-config.php including your database password and, for an online store, customer and order data as well. So never leave a backup as a ZIP file in a public web directory, because then anyone who guesses the filename can download it. Store backups in encrypted form and, preferably, within the EU. Under the GDPR, you are responsible for that personal data, even if it’s stored in a backup.
Restoring a backup and testing it beforehand
To restore a backup, restore the files and database from the same restore point, then resave the permalinks and clear the cache. You can read about which restore point to choose and what to check afterward in Restore a backup. I think what you do before that happens is more important. A backup you’ve never restored is just a hypothetical scenario—just as insurance is only worth anything as long as the policy is still in effect. That’s why I run a recovery test every quarter.
- Choose any backup—don't always pick the most recent one.
- Restore it to a copy of your site, such as a clone in Installatron.
- Check the login page, the homepage, a form, the media library, and—if it's an online store—the most recent orders.
- Write down the date and the result so you can see if anything changes.
Restoring the system isn't always the solution, by the way. If your system has been hacked, you'll often just restore the malware along with it, because the vulnerability is still there. In that case, read this first Remove malware, or leave the repair to WordPress hacked. After a failed update, disabling a single plugin is often enough; see Site Down After an Update.
With a WooCommerce online store, the situation is even more sensitive. Orders come in constantly, so a daily backup could miss an entire day’s worth of orders. Therefore, never blindly restore an old database to a live online store; instead, first export the orders from after the restore point. Instructions on how to set this up can be found in WooCommerce Backup. If you want backups and recovery tests to be a regular part of your online store maintenance, we'll include that in WooCommerce Management.
WordPress Migration: Which Approach Is Right for Your Situation?
A WordPress migration involves moving your entire site, and the approach you take depends on what’s changing. If you’re moving to a different hosting provider but keeping the same domain, only the server will change. You should test the new environment before the DNS change and make sure your email is transferred as well. That process is explained step by step in the Step-by-Step Guide to Moving Your WordPress Website.
If your site gets a different domain or URL, you'll need to update the site URL, replace the old addresses in the database, and set up 301 redirects from the old to the new, so that visitors and Google can find you. To do this, read Change the WordPress URL. If you're just transferring your domain to another registrar, your site will remain online, but you'll need to transfer your DNS records—and especially your MX records—with it; otherwise, your email will stop working. That's what this is about Transferring a Domain and DNS. If you’re putting a site from a staging environment or your own computer live, replace the test URLs and allow search engines to index the site again. And if you’re switching from http to https, you’ll need a valid SSL certificate, the correct site URL, and redirects.
Migration in Five Phases
A WordPress migration to a different hosting provider takes place in five phases, from backup to post-migration verification. The main steps are outlined below. You can find the technical steps for each phase in the migration guide above.
- Create a complete backup and an inventory of your DNS records and email accounts. Use your email hosting If the mailboxes are on the same domain, move them before the domain change—for example, using imapsync or by linking both accounts via IMAP in your email program.
- Migrate the site to the new server, either using a migration plugin or manually. Installatron also has an import feature for an existing installation; to see if it works with your old host, please check with our support team.
- Test the new site using a temporary URL or your hosts file while visitors are still on the old site.
- Set the TTL one day in advance, and then update the DNS using the A record or the nameservers.
- Check SSL, forms, email, and Google Search Console, and don't cancel your old hosting until a week has passed.
If you do it this way, your site won’t go offline during the migration. There are, however, two pitfalls I often come across. The first is searching and replacing in the database. WordPress stores many settings as serialized data, and if you replace URLs in that data using a regular text editor, you’ll corrupt it. So always use a tool that understands this, such as wp search-replace in WP-CLI. The second pitfall involves online store orders. Orders received between the export and the DNS change will be lost. Therefore, move your online store during a quiet time, temporarily pause order processing, or transfer the database one last time as a final step.
Migrate it yourself or have someone else do it?
Most people can move a small website without an online store on their own using a migration plugin. If you have an online store, multiple websites, your own email on the domain, or a tight deadline, I’d recommend having someone else do it. A forgotten MX record or an error in the DNS can easily cost you more time than you’d have liked to save. At Surver, the moving service The entire migration process is included free with every package, with no limit on the number of sites or online stores. We’ll migrate your website, email accounts (including folders), DNS records, and domain, and properly configure the site URL and redirects. An online store will be briefly in maintenance mode during the migration.
You don't have to handle everything yourself when it comes to backups, either. At Managed WordPress Hosting We automatically create daily, weekly, and monthly backups, which are stored on external servers in separate data centers within Europe. With the shared hosting plans, you can restore them yourself at no cost using JetBackup 5 in cPanel—separately for files, databases, or email accounts. You can create additional backups using Installatron, where you can also clone your installation for recovery testing. One thing to keep in mind is that the current state isn’t automatically preserved during a restore, so be sure to create your own backup first. If you’re on Surver Cloud, please contact support.
Backups are one part of maintenance. If you'd rather have someone else handle backups, updates, and checks entirely, check out WordPress maintenance. You can read more in these articles.
- WordPress Management: The Complete Guide, the category hub for everything related to management.
- The Maintenance Checklist based on what you do on a weekly, monthly, and yearly basis.
- Updating WordPress Safely, for the core, themes, and plugins.
- Turn automatic updates on or off, and what's better to do by hand.
- Undo Changes with revisions, without a backup.
- Resetting WordPress, always after making a backup.
- Check the WordPress version and WordPress 7.0, about versions and when to update.
- Risks of a WordPress Site Without Maintenance.
Frequently Asked Questions
Does my hosting provider automatically create a WordPress backup?
Most managed hosting providers do this, but be sure to ask how often, how long the backups are retained, and where they are stored. At Surver, this happens automatically, with daily, weekly, and monthly backups on external servers within Europe. It’s still a good idea to keep an extra copy outside your hosting provider.
Which backup plugin is the best?
There’s no single “best” plugin for everyone. If you have hosting backups on external servers—such as with Surver—then a plugin is especially useful as an extra copy outside of your hosting. Choose one that can write to cloud storage and test the restore process at least once.
How do I copy an entire WordPress site?
If you want a copy on the same hosting account, create a clone using our Installatron. If the site is moving to a different server, use a migration plugin or have the migration service handle it.
How long does a WordPress migration take?
For an average website, the migration itself is often completed within a few hours. After that, the DNS change takes effect, depending on the TTL. At Surver, the default TTL is 600 seconds, so lowering the TTL is especially helpful if your previous provider uses a higher value.
