- Back up most WordPress sites daily; back up an active WooCommerce store every hour or on every order.
- A real backup includes both the files (wp-content, uploads, themes, plugins) and the database. One without the other cannot restore a working site.
- Follow the 3-2-1 rule: 3 copies, on 2 different media or locations, with 1 copy off-site.
- A backup you have never restored is a guess. G7Cloud restore-tests every backup nightly with a real restore into a sandbox.
- Even on managed hosting, keep one off-site copy you own (your own S3, R2 or SFTP), so you can leave any host with your data.
How often should I back up a WordPress site?
Back up most WordPress sites once a day. Back up an active WooCommerce store more often: every hour, or on every order, because a daily backup can lose a full day of sales. A simple brochure site that rarely changes can be backed up weekly. Match the interval to how much work you can afford to lose.
The real question behind "how often" is a business one: how many hours of new content, orders or comments are you willing to redo by hand? That number is your recovery point. If losing four hours of orders would hurt, a nightly backup is already too slow. Set the interval first, then pick a host and tools that can meet it.
| Site type | How often to back up | How long to keep it |
|---|---|---|
| Brochure or low-change site | Weekly, plus before every change | 30 days |
| Business site or active blog | Daily | 30 to 60 days |
| Active WooCommerce store | Hourly, or on every order | 60 to 90 days |
| Membership or forum site | Hourly to daily, by activity | 60 to 90 days |
A starting point. Raise the frequency when losing an hour of data would cost you real money or trust.
Always take a manual snapshot right before a risky change: a plugin update, a theme swap, a bulk edit, or a PHP version bump. Scheduled backups protect you from accidents. A pre-change snapshot protects you from your own next click.
What is the best WordPress backup strategy?
The best WordPress backup strategy runs on a schedule without you, keeps copies away from the server they protect, captures both files and database together, and proves it works by restoring. Miss any one of those and you have a backup that looks fine in a dashboard but fails on the day you need it.
Most site owners do the opposite. They install a backup plugin, set it to run nightly, and never look again. It feels done. But a plugin backup stored on the same machine as your site dies with that machine, and a job that reports success has only proven a file was written, not that the file can rebuild your site. A good strategy removes both of those blind spots on purpose.
Four traits of a backup you can trust
It runs automatically, with no human to forget it. It stores copies off the server it protects. It captures files and database in one consistent set. And it is restore-tested, so a real restore has actually succeeded rather than merely being scheduled.
On G7Cloud, backups run on schedules you choose: daily, weekly or monthly, plus manual snapshots before risky work. You can send copies to an off-site target you own, and restores are granular, so you can bring back one file, one database, or the whole site. See how it fits together on the backups feature page.
What is the 3-2-1 backup rule in plain terms?
The 3-2-1 rule is the oldest safe habit in backups, stated plainly: keep 3 copies of your data, on 2 different media or locations, with 1 copy off-site. The live site counts as one copy. So you need at least two more, and at least one of those must live somewhere your server cannot take down with it.
| Rule | In plain terms | A WordPress example |
|---|---|---|
| 3 copies | The live site plus two backups | The running site, a backup on the host, and a copy elsewhere |
| 2 media or locations | Do not keep every copy in one place | One backup on the host platform, one in cloud object storage |
| 1 off-site | One copy the server cannot destroy | A copy in your own S3, R2 or SFTP, on a different provider |
The point of 3-2-1 is that no single failure, a bad disk, a hack, a deleted account, can wipe out every copy at once.
A backup on the same server is not a backup
If your only backup sits on the machine that runs your site, one disk failure, one ransomware event, or one compromised account takes the site and the backup together. The off-site copy is the whole point of the rule. Do not skip it.
What does a complete WordPress backup actually include?
A complete WordPress backup includes two things that must be captured together: the files and the database. Files hold your uploads, themes, plugins and configuration. The database holds your posts, pages, products, orders, users, settings and comments. Restore one without the other and you get a broken site, not a working one.
| Part of the site | Where it lives | What you lose without it |
|---|---|---|
| Media and uploads | wp-content/uploads | Every image, PDF and attachment on the site |
| Themes and plugins | wp-content/themes, wp-content/plugins | Your design and all custom functionality |
| Configuration | wp-config.php and related files | Database credentials, keys and site constants |
| Content and settings | The MySQL or MariaDB database | All posts, pages, products, orders, users and options |
A files-only backup restores an empty shell. A database-only backup restores content with no images and no theme. You need both.
Files-only and database-only backups leave you stranded
This is the most common backup mistake we see. A plugin backs up wp-content but skips the database, or exports the database but not the uploads folder. Either way the restore produces a site that will not load correctly. Always confirm your backup contains both, in one consistent set.
On G7Cloud every site has its own dedicated container and its own database, with no shared tables. Backups capture the files and that database together, so a restore brings back a matched, consistent site rather than a mismatched half of one.
Why do untested backups fail when you need them?
Untested backups fail because a backup job reports success when a file is written, not when that file can rebuild your site. The archive can be truncated, the database dump can be inconsistent, a plugin can hit a timeout or memory limit halfway through, and the dashboard still shows a green tick. You only discover the gap during a restore, which is the worst possible moment.
The first restore is where the surprises live
In our experience running WordPress sites, the first real restore attempt is where hidden faults show up: a missing database, a truncated archive, or a silent plugin failure nobody noticed. A green dashboard tick is not evidence the copy works. Only a completed restore is.
The failure modes are quiet by design. On a large site, a backup plugin can exhaust PHP memory or hit the maximum execution time and stop mid-archive, writing a file that looks complete by size but is not. A database dump taken while orders are being written can capture a half-finished transaction. None of this shows up until someone tries to restore, because nothing tested the copy.
Restore-tested nightly, beyond simply scheduled
G7Cloud restore-tests every backup automatically, every night: a real restore into an isolated sandbox, verified. If a backup cannot actually be restored, we know that night, not on the day you need it. This is a real restore, not a checksum.
"Ask your host one question: when was the last successful test restore? If the answer is a shrug, you do not have backups. You have hope."
How long should I keep WordPress backups?
Keep at least 30 days of backups for a typical business site, and 60 to 90 days for a store or membership site. Retention matters because the damage you most need to recover from, a malware infection, a bad plugin, a slow data corruption, is often invisible for days. If you only keep three days, you may find every copy already contains the problem.
A useful pattern is layered retention: keep daily backups for the last month, weekly backups for a few months, and a monthly backup for the year. This gives you fine-grained recovery for recent mistakes and a long tail for problems you catch late, without storing a copy for every single day forever. On G7Cloud you set daily, weekly and monthly schedules, so this layering is built in rather than something you script by hand.
Match retention to your risk, not to storage cost
Storage is cheap; a store that cannot roll back to before a fraud event is expensive. If you handle orders or personal data, lean towards 90 days. Pair long retention with the security practices in our WordPress security guide so you catch problems sooner.
How do I run a restore drill without breaking my live site?
Run a restore drill by restoring a backup into a separate staging copy, never over production. A restore drill proves your backup actually rebuilds a working site, and it costs nothing but half an hour. The rule that keeps it safe is simple: restore into a new environment, check it there, and never point the restore at your live database or files.
Here is a drill you can run today. It takes about thirty minutes and tells you the one thing a green backup dashboard never will: whether the copy works.
| Step | What you do | What it proves |
|---|---|---|
| 1. Pick a backup | Choose a recent scheduled backup, not a fresh manual one | The routine backups are the ones you rely on |
| 2. Create a staging site | Spin up an empty staging or a local copy, separate from production | The restore never touches your live site |
| 3. Restore into it | Restore files and database into the staging environment | The archive and dump are complete and readable |
| 4. Log in and click around | Load the home page, an inner page, and wp-admin; check images | The site actually renders, rather than only unpacking |
| 5. Note the time | Record how long the restore took start to finish | You know your real recovery time before an incident |
Do this once a quarter. The first drill almost always finds something: a missing upload, a wrong URL, or a slower restore than you assumed.
Never restore over production to test
Restoring a backup on top of your live site to see if it works can destroy the good data you still have if the backup is bad. Always restore into a separate staging or local environment. If your host offers granular restore, test bringing back a single file first, before ever touching the whole site.
On G7Cloud, restores are granular: bring back the full site, a single file, or a single database. That means a real drill can be as small as restoring one file into a preview, and a real incident never forces you to roll back a whole day of orders to recover one corrupted upload. Our preview environments and developer tools give you a safe place to restore into.
Do I still need my own backups on managed hosting?
Yes. Even on good managed hosting, keep at least one off-site copy that you own and control. Host backups protect you from server failure. Your own off-site copy protects you from something rarer but worse: a billing dispute, an account suspension, or simply deciding to leave. If every copy of your data lives inside one provider, that provider owns your exit.
This is not a knock on managed hosting; it is how professionals think about ownership. A host that does backups well removes almost all of your day-to-day risk, which is one of the real differences between managed and shared hosting. But the 3-2-1 rule still applies, and the "1 off-site" copy is the one you should hold yourself. Good hosts make this easy rather than fighting it.
Own the off-site copy
On G7Cloud you can send backup copies to your own S3 bucket, Cloudflare R2, or any SFTP server you control. Combined with our nightly restore-testing, that gives you both a host that proves its backups work and a copy that is yours to keep, wherever you go next.
The same ownership principle runs through the platform. Your site has its own dedicated container and database, and if you ever move to us, our team performs a free assisted migration with a preview you approve before anything cuts over. Backups are just the part of ownership you notice on your worst day rather than your first.
Frequently asked questions
How often should I back up my WordPress site?
Back up most WordPress sites daily. Back up an active WooCommerce store hourly or on every order, because a daily backup can lose a full day of sales. A rarely changed brochure site can be backed up weekly, as long as you also take a manual snapshot before any change.
What is the 3-2-1 backup rule for WordPress?
The 3-2-1 rule means keeping 3 copies of your data, on 2 different media or locations, with 1 copy off-site. Your live site is one copy, so you need at least two more, and one of those must live somewhere your server cannot take down with it, such as your own cloud storage.
Does a WordPress backup include the database?
It must. A complete WordPress backup captures both the files (uploads, themes, plugins, configuration) and the database (posts, pages, products, orders, users and settings). A files-only backup restores an empty shell, and a database-only backup restores content with no images or theme, so you need both in one consistent set.
How do I test a WordPress backup?
Restore a recent scheduled backup into a separate staging or local site, never over production. Then log in, load a few pages, and check that images and the admin area work. This proves the backup actually rebuilds a working site and tells you your real recovery time. Do it once a quarter.
Do I need my own backups if my host already backs up my site?
Yes. Host backups protect you from server failure, but you should still keep at least one off-site copy you control, on your own S3, R2 or SFTP. That protects you from account suspension, billing disputes, or simply choosing to leave, and it satisfies the off-site part of the 3-2-1 rule.
How long should I keep WordPress backups?
Keep at least 30 days for a typical business site and 60 to 90 days for a store or membership site. Longer retention matters because malware and data corruption often go unnoticed for days, so a short window can leave every copy already infected. Layer daily, weekly and monthly backups to balance detail against storage.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →