This guide is for bloggers, small business owners and agency owners who run WordPress and want backups that still exist on the day something goes wrong. It covers what a complete backup contains, why a host’s backups should not be your only copy, how often to back up, where to store copies, and how to prove a backup works by restoring it somewhere safe before you need it.
What a full WordPress backup includes
The official WordPress backups documentation says a complete backup has two parts: the files and the database. You need both to fully restore a typical site.
- Files: the WordPress directory on your server, which includes core files, themes, plugins, uploads,
wp-config.phpand.htaccess. - Database: stored separately, usually in MySQL or MariaDB. It holds your posts, comments and links. Copying the WordPress folder does not copy it.
The documentation notes that a database backup is normally an export file (such as .sql, .gz or .bz2) that must be imported into MySQL or MariaDB to restore. For the order of work, it advises backing up the database first and then the files, and keeping both in the same folder or zip so they stay together. When restoring, put the files back first and then import the database. If database credentials changed during a move, update wp-config.php to match.
Why host backups alone are not enough
Many hosts offer backup tools, and the WordPress documentation says to check with your host about what is available. That is a good first layer. It should not be the only one, for reasons that follow from the basic idea of keeping copies in different places:
- Same place as the site. If a host backup lives on the same account or infrastructure as the site, a problem with that account can affect both. The WordPress documentation recommends keeping backups in different locations, such as the hosting server, cloud storage and a local computer.
- You may not control it. Retention, frequency and restore options are set by your plan. Check the details in your host’s own documentation instead of assuming them.
- Restores are untested. A backup you have never restored is a hope, not a plan.
The 3-2-1 idea
CISA’s small business guidance on backing up data calls the 3-2-1 rule a trusted guideline: keep three total copies of important files, on two different types of media, with one copy off-site, away from your business location. For a WordPress site, that could mean the live site (copy one), a host or plugin backup on the server (copy two), and an automatic copy sent to separate cloud storage (copy three, off-site). The server copy and the live site usually share the same hardware, so the off-site copy is the one that protects you if the server is lost.
The same CISA page recommends choosing a backup solution that runs automatically and regularly, and testing your procedure so you can restore data both fully and partially. It also suggests being able to roll data back at least seven days if needed.
How often to back up: blogs versus stores
The WordPress documentation says to back up regularly and always before an upgrade. It says smaller sites with few posts may back up weekly, while high-activity sites may need daily backups. CISA’s page does not give a fixed interval, so use one question to set your own schedule: how much new data could you afford to lose?
The table is a planning aid, not a rule from any one source. The store row is least certain, because restoring an old database can erase recent orders.
| Site type | What changes | Reasonable starting point |
|---|---|---|
| Small blog, a few posts a month | Database changes slowly; uploads grow occasionally | Weekly, plus before every update (consistent with the WordPress documentation) |
| Busy blog or membership site | Frequent posts, comments, new users | Daily database backup; files can follow a slower schedule |
| Online store | Orders and customer records are created constantly | Daily at minimum; consider more frequent database backups, and think through how restoring would affect orders placed after the backup |
Off-site storage options
The WordPress documentation says plugins can run scheduled backups and help manage the collection, and points to backup plugins in the WordPress Plugin Directory. It also suggests keeping at least 3-5 recent backups in different locations. Your realistic off-site choices are:
- Cloud storage such as Google Drive, Dropbox or Amazon S3, usually connected through a backup plugin.
- An FTP or SFTP server you control, separate from your web host.
- A local computer or external drive for periodic manual copies. The documentation recommends an occasional manual backup to confirm that the automated process is working.
As one example of what a plugin can do, the UpdraftPlus page on WordPress.org says UpdraftPlus can back up and restore WordPress sites on a schedule. According to that page, the free version can send backups to Dropbox, Google Drive, Amazon S3 or compatible services, Rackspace Cloud, FTP, DreamObjects, OpenStack Swift and email, with schedules ranging from every 2 hours to monthly. Features such as incremental backups, backups to more than one location and Backblaze B2 or OneDrive storage are listed under the premium version. This is not an endorsement; the plugin directory has many backup plugins, so compare their current descriptions, update history and support before choosing.
How to set up automatic off-site backups
The exact screens differ by plugin, so treat these as the general sequence.
- Choose a backup plugin from the Plugins > Add New screen in WordPress admin, and read its description, version compatibility and reviews first.
- Install and activate it, then open its settings page.
- Set the schedule for files and database separately if the plugin allows it, based on the table above.
- Connect a remote storage account and authorise the plugin. Use a storage account that is not the same as your hosting account.
- Set how many backups to keep. The WordPress documentation suggests at least 3-5 recent copies.
- Run a manual backup straight away and confirm the files appear in your remote storage.
- Set a calendar reminder to check the remote storage monthly and make sure new backups keep arriving.
If you use a migration plugin to move or copy sites, keep it updated. Impact Digital has covered a security alert for the All-in-One WP Migration plugin, a reminder that any plugin with access to your whole site deserves attention to updates. For a broader look at plugin choices, see this guide to essential WordPress plugins.
How to test a restore on staging
A restore test confirms that the backup is complete and that you know the steps. Do it on a staging copy or a separate test site, never on your live site. Your host may offer staging; check its documentation for how.
- Create an empty test site, on a subdomain or local environment, with its own new database.
- Download or retrieve the latest backup from your off-site storage, not from the live server. This also tests that the off-site copy is usable.
- Following the documented order, restore the files first, then import the database. If the test database has different credentials, update
wp-config.php. - If the test site has a different address, make sure URLs are updated; some backup plugins include a search-and-replace feature for this, so check your plugin’s documentation.
- Check that the front page, a few posts, images, menus, forms and the admin login all work.
- Write down how long it took and what went wrong, and fix the gaps in your process.
Common mistakes
- Backing up only files or only the database. Either alone is incomplete.
- Storing every copy on the same server. This defeats the off-site part of 3-2-1.
- Never testing a restore. The first restore should not be during an emergency.
- Forgetting to back up before updates. The WordPress documentation says to always back up before an upgrade.
- Ignoring failed backups. Automatic jobs can fail quietly; the documentation recommends occasional manual backups to check the process.
- Leaving credentials and backups exposed. A backup contains your database and
wp-config.php, so protect storage accounts with strong passwords and do not leave backup files in public web folders.
Key takeaways
- A full backup means both the database and the files, restored in the right order.
- Host backups are a useful layer but should not be your only copy.
- Follow 3-2-1: three copies, two kinds of media, one off-site.
- Back up weekly for small sites and daily for active ones, and always before an upgrade.
- Automate, but check the remote storage regularly.
- Test a restore on staging so you know the process works.
FAQ
Is my host’s backup enough?
It is a good start, but keep at least one copy somewhere separate from the host. The WordPress documentation recommends copies in different locations, such as the server, cloud storage and a local computer.
How many backups should I keep?
The WordPress documentation recommends at least 3-5 recent backups stored in different locations.
Do I need a plugin?
No. The documentation describes manual backups using phpMyAdmin for the database and file copying for the files. Plugins automate the schedule and the off-site transfer, which is why many site owners use them.
Can I restore a backup directly onto my live site to test it?
It is safer to test on a staging or separate test site first. Restoring over a live site replaces its current content with older data.
