Until you have restored a backup, you are only assuming it works. It is easy to install a backup plugin, watch the first run finish and not look at it again until something breaks. A WordPress backup strategy closes that gap by settling four decisions in advance: how often backups run, where the copies live, how long you keep them, and how you prove they restore.
This guide covers those decisions, including what to ask your host before you rely on its daily or weekly backups. To set up a backup or carry out a restore, follow our step-by-step guide to backing up and restoring WordPress. Backups are also one item on the wider WordPress security checklist, and they are the item that lets you recover when the others fail.
What is the 3-2-1 backup rule for WordPress?
The 3-2-1 rule means keeping three copies of your data, on two different types of storage, with one copy kept off-site. A 2012 paper produced for US-CERT sets it out as 3 copies of any important file (1 primary and 2 backups), on 2 different media types, with 1 copy stored offsite.
Peter Krogh has said he coined the term 3-2-1 Rule while writing the first edition of The DAM Book. In the same account he makes clear that he did not invent the idea of keeping three copies with one offsite. He turned an existing practice into a rule that is easy to remember.
For a WordPress site, the three copies usually look like this:
- Copy 1: the live site on your hosting server.
- Copy 2: a backup stored somewhere other than that server, such as a cloud storage account.
- Copy 3: an offline copy, such as a downloaded archive on an external drive that is not connected to anything.
A backup kept on the same server as the live site is useful for quick rollbacks, but it does not count as your off-site copy. If that server fails or your hosting account is locked, you lose the site and that backup together.
How often should you back up WordPress?
Back up as often as your site changes. A simple test is to ask how much work you could afford to redo. If losing a week of edits would cost you an afternoon, weekly backups are enough. If losing an hour of orders would cost you money and customers, back up the database at least every hour.
That window is your recovery point: the most recent moment you can roll back to. Anything that happened after it is gone.
WordPress’s own documentation says to back up your database regularly and always before an upgrade, and suggests weekly backups for smaller sites and daily backups for high-activity sites. The table below builds on that baseline. The hourly rows and the retention periods are our recommendations rather than the handbook’s.
| Site type | What changes | Recommended frequency | Keep backups for |
|---|---|---|---|
| Brochure or business website | Pages, contact details, occasional posts | Weekly full backup, plus one before every update | 30 days |
| Blog publishing every week | New posts, comments | Daily database, weekly full backup | 30 to 60 days |
| WooCommerce store taking orders daily | Orders, customers, stock | Hourly database, daily full backup | 60 to 90 days |
| Membership or course site | User accounts, lessons, progress | Hourly database, daily full backup | 60 to 90 days |
The retention period grows as the data gets harder to recreate. You can rebuild a brochure page by hand, but you cannot rebuild a month of customer orders.
Two habits apply to every row:
- Take a fresh backup before every plugin, theme or WordPress core update. If the update breaks the site, you roll back instead of repairing it by hand.
- Back up the database more often than the files. Orders, comments, new posts and settings all live in the database, while most files change only when you upload media or update a plugin.
Where should you store WordPress backups?
Keep at least one copy off the server that runs your site, and one copy offline. A backup that lives only on the live server fails at the same moment the site does, whether the cause is a hardware fault, a compromise or a suspended account.
Plan your storage in layers:
- A backup on the hosting server. Your host creates it, or you create it from your control panel. It is the quickest to restore, but it shares the server’s fate. If you are still choosing a control panel, our cPanel vs DirectAdmin comparison covers the differences.
- An off-server cloud copy. A backup plugin uploads copies on a schedule to a storage account you control. Google Drive and Dropbox are examples of destinations. Pick one you already use and can log into quickly when something goes wrong.
- An offline copy. A periodic download to an external drive that stays disconnected from your computer and your network between updates.
The offline layer matters because attackers go after backups. CISA’s #StopRansomware Guide tells organisations to keep offline, encrypted backups of critical data, because most ransomware actors attempt to find and delete or encrypt accessible backups.
The same CISA guide warns that automated cloud backups may not be sufficient on their own: if an attacker encrypts local files, those files sync to the cloud and can overwrite unaffected data. A Dropbox or Google Drive folder that mirrors your computer is convenient, but it is not your offline copy.
A brochure site can run on the first two layers plus an occasional offline download. A store or membership site needs all three, with the offline copy refreshed at least once a month.
How long should you keep WordPress backups?
Keep backups for longer than it could take you to notice that something is wrong. WordPress’s documentation recommends keeping at least 3–5 recent backups, stored in different locations. Treat that as the minimum.
The reason to keep more is detection time. Some problems do not announce themselves: spam links injected into old posts, a hidden administrator account, or a contact form that quietly stopped saving entries. If you keep five daily backups and the problem started eight days ago, all five copies contain it, and you have nothing clean to restore.
For WordPress backup retention, we recommend a layered scheme:
- The last 7 daily backups, for a fast rollback after a bad update or an accidental edit.
- The last 4 weekly backups, for problems you notice within a month.
- The last 3 to 6 monthly backups, for problems that stayed hidden for longer.
- One yearly archive, for your own records and for questions about what the site looked like a year ago.
If storage space is tight, keep fewer daily copies before you cut monthly ones. The older copies are the ones that save you when a problem is discovered late.
Is your host’s backup enough? Questions to ask before you rely on it
A host backup is a useful layer, but it is not enough on its own. It lives with the company that runs your site, on a schedule you did not choose. cPanel & WHM’s documentation shows that on servers running that software, the server administrator chooses whether backups run daily, weekly or monthly and sets how many copies of each kind the system keeps. Until you ask, you do not know what you are getting.
A plan page that says daily backups answers only one of these questions. Put all five to your host, in writing, and keep the reply:
- How often do backups of my account run?
- How long are copies kept, and how many are kept at a time?
- Are the copies stored off the server my site runs on?
- Can I restore a backup myself, or do I need to open a support request?
- Do you test that your backups restore?
LuminWeb WordPress Hosting includes automatic backups. Ask our support team how often they run and how long they are kept, then add your own off-server copy so your 3-2-1 setup is complete.
Backup plugin, control-panel backup or host backup: which layer does what?
Use them together. Each one covers a failure the others miss.
| Backup type | What it does well | Where it falls short | Best used as |
|---|---|---|---|
| Host server backup | Runs without your input and does not depend on your WordPress site working | You do not set the schedule or retention, and it is tied to your hosting account | A fallback layer you confirm with the five questions above |
| Control-panel backup (cPanel or DirectAdmin) | One downloadable archive of your account, useful before a migration to a new host | You create it when you need it, and large archives take time to build and download | On-demand snapshots and migrations |
| Backup plugin | Your own schedule, separate database and file schedules, uploads to cloud storage | Runs inside WordPress, so a compromised or broken site can stop it, and it can fail without telling you | The off-server cloud layer |
| Cloud backup service | Off-site by design | An ongoing subscription, and you depend on a third party staying available | An extra off-site copy for high-value sites |
If you are weighing up WordPress security plugins and one of them includes backups, that feature can serve as your off-server layer. Do not let a single plugin hold your only copy. For the click-by-click steps for each method, use the WordPress backup and restore guide.
How to test a WordPress backup: the quarterly restore drill
Test a restore at least once a quarter, in a staging copy of your site. CISA’s guidance tells organisations to keep backups and regularly test their availability and integrity in a disaster recovery scenario. WordPress’s documentation recommends backing up those automatic backups with a manual backup once in a while to make sure the process is working.
Two conditions protect your live site, and both apply before you restore anything:
- Take a fresh backup of the live site first, and download it off the server. You then have a known-good copy if anything in the drill touches the live site.
- Restore only into a separate staging copy with its own database, never over the live site. Check this once you have set up staging in step 1 and before you restore anything in step 2. How you check depends on where staging lives:
- If staging is on your hosting account, open its wp-config.php file and compare its DB_NAME line with the DB_NAME line in the live site’s wp-config.php. If the two names match, stop: staging is pointing at the live database, and nothing in the drill is safe to run until you fix it.
- If staging is a copy on your own computer, open its wp-config.php file and read the DB_HOST line. It must name your own computer, usually localhost. If it names your hosting server instead, stop: staging is connected to a database on the server, and nothing in the drill is safe to run until you fix it.
With both conditions met, run the drill:
- Set up the staging copy. Use a subdomain such as staging.yoursite.com on your hosting account, or a WordPress copy on your own computer.
- Restore your most recent off-server backup into staging. Use the off-server copy rather than the one on the host, because that is the copy you would need if the server were lost. When you restore into staging, use the backup plugin installed in staging, or import the database file into the staging database by its name. Do not use your host’s control-panel restore tool for the drill, because it can write back to the live site. The backup and restore guide walks through the restore itself, with two extra checks for staging. If the backup includes a wp-config.php file, do not let it replace staging’s own copy: download staging’s wp-config.php before you extract the files, so you can put it back. After the files are in place, and before anything touches the database, open staging’s wp-config.php again and repeat the check from the conditions above. If staging is on your hosting account and DB_NAME now names the live database, or staging is on your own computer and DB_HOST now names your hosting server, stop and put staging’s own file back before you continue. Once the check passes, restore the database and change the site address stored in the staging database to the staging domain, or its links will send you back to the live site.
- Walk through the pages that matter. Check that the homepage loads, you can log in, a key product or service page loads, the contact form sends, and, on a store, an item can go into the cart and reach checkout.
- Write down what failed. Note missing images, lost settings or any step that needed a manual fix, and correct your backup setup before the next drill. Once a year, restore one of your oldest kept backups into staging as well, to confirm the deeper copies work.
Run the drill again whenever you change your backup plugin, your storage destination or your host. If your site is ever hacked, you will already know which backup restores cleanly, and our recovery guide for hacked WordPress sites covers the rest of the response.
Backup mistakes that quietly break recovery
Not watching for failures. A plugin backup can stop running without any visible sign. Turn on failure alerts if your plugin offers them, and look at the backup log each month.
The other mistakes undo decisions covered above: keeping the only copy on the live server, backing up files without the database, treating a synced cloud folder as your offline copy, keeping too few copies, skipping the backup before an update, and never testing a restore.
Backup realities for sites run from Ghana
Power and bandwidth shape how this plan works in practice. A few adjustments make it more dependable:
- Run full backups in quiet hours. Building and uploading a large archive puts load on the server, so schedule it overnight, when fewer customers are on the site.
- Plan the offline download around your connection. Scheduled plugin uploads to cloud storage go from the hosting server, so they use none of your own mobile data. Only the monthly offline download comes over your connection: do it on a fixed broadband line or with a data bundle sized for it, and confirm the file opens before you delete an older copy.
- Plan around power cuts. Copy the archive to your external drive from a laptop running on battery. A power cut during the copy can leave you with an incomplete file.
A starter 3-2-1 plan you can set up this week
If you are starting from nothing, these four steps put a complete WordPress backup strategy in place.
- Ask your host the five backup questions and keep the reply. Whatever the answers, treat the host backup as one layer.
- Set a backup plugin to upload to a cloud storage account: the database daily (hourly for a store), and files weekly. That is your off-server copy.
- Download a monthly archive to an external drive that you keep disconnected. That is your offline copy.
- Put the quarterly restore drill in your calendar.
Where to go next
- The WordPress security checklist covers the other protections around your backups.
- The step-by-step guide to backing up and restoring WordPress shows how to create each type of backup and how to restore one.
- The recovery guide for hacked WordPress sites takes you through a compromise from first signs to clean-up, and WordPress login security covers closing the way in so an attacker cannot return after you restore.
- The plugin security audit and best WordPress security plugins compared cover the plugins your site depends on.
If you run a WordPress site in Ghana, LuminWeb WordPress Hosting includes automatic backups, and this guide shows you how to add the off-server and offline copies around them. See our hosting plans and pricing for current plans.
