Website Backup and Recovery Drills: Frequency, Offsite Storage, and Verifying Restorability

Bottom line first: The only acceptance test for a backup isn’t “having a backup,” it’s “being able to restore.” And the acceptance test for being able to restore is “having drilled it.” Run daily incrementals kept for 14 days, weekly fulls kept for 8 weeks, and snapshots taken before major changes kept for 90 days. Keep backups and the site on different servers, different accounts, and in different regions, and run a full recovery drill every six months. A complete restore for a small or mid-sized site usually takes 30–120 minutes.

1. The only acceptance test for a backup is “being able to restore”

First, let’s draw the boundaries of this article:Security Baseline covers how to keep intruders out at the door, and Monthly Maintenance covers where backups fit into the monthly routine. This article covers backups themselves—what to back up, where to store it, how often to verify it, and how long a restore takes. Defense is prevention, maintenance is rhythm, and backups are the last line of fallback. The three can’t substitute for each other.

Most companies’ website backups only “look like” they exist: the hosting panel shows a successful backup, backup records sit in a plugin list, and everyone assumes they’ll be able to recover when something goes wrong. Only on the night of an incident do three things surface: the backup file is corrupt or hasn’t been updated in months, the backup and the site were on the same host and were lost together, and nobody knows the actual recovery steps. The first is a quality problem, the second is a storage problem, and the third is a process problem. These three problems map to the three sections that follow.

Fake Backup Pattern	How it looks day to day	What happens during an incident
Same-host backup	The panel shows a successful backup, and nobody downloads it	Lost along with the site when the host fails
Backing up only the database, not the files	Backup is small and runs fast	After restore, the theme is missing, the layout is broken, and all images fail
Backup job has been erroring for a long time	A red warning occasionally appears in the dashboard and nobody deals with it	The most recent usable backup is months old, and all data in between is lost
Integrity has never been verified	Backup file size fluctuates wildly	At restore time, the archive turns out to be corrupt and won’t extract
Recovery steps exist only with the service provider	No written process documentation	No one can perform a restore once support is off duty or unreachable

To judge whether your backups are real, you only need to answer one question: when was the last time you fully restored the site from a backup, and how long did it take? If you can’t answer, treat it as having no backup. This judgment has nothing to do with “backup shows success”—a successful job notification only proves the job ran, not that the result is usable.

2. What to back up: four asset types, and skipping one leaves your restore incomplete

List every backup target before you talk about frequency. A typical standalone WordPress site has four asset types you must cover. Miss any one of them and what you restore is an incomplete site.

Backup target	What it covers	What happens if you skip it	Recommended frequency
Database	Posts, pages, form submissions, user and order data	All content and inquiry records are lost	Daily
Files, themes and plugins	Core files, theme code, plugins and their settings	Features can’t be restored and the front end breaks	Weekly and before any change
Uploads directory	Product images, PDF resources, case study images and videos	Every image on the site returns a 404 and downloads stop working	Weekly
Configuration and certificates	Web server config, SSL certificates, exported DNS records	The site won’t start, or HTTPS throws errors site-wide	Every time you make a change

Three things to add. First, the uploads directory is usually the largest, and plenty of teams skip it because of the size — then they restore a site with no product images, which to a buyer is barely different from no site at all. Second, configuration and certificates are the easiest to miss, because they usually live at the hosting layer rather than in the site builder, and a plugin’s backup scope can’t reach them. Third, inquiry and order data live in the database, which makes it the most commercially valuable of the four: lose an image and you can upload it again, but lose a customer lead and there’s no way to recover it. So the database backup frequency has to be set at the highest tier on its own.

3. Three backup schedules and their retention periods

Frequency and retention are a matched pair. Set a frequency without a retention period and you haven’t set anything.

Tier	Frequency	Retention period	Typical scenarios it covers
Daily incremental	Once a day	14 days	Accidentally deleted posts, wrong page edits, rolling back the day’s changes
Weekly full backup	Once a week	8 weeks	Gradual database corruption, needing to roll back several weeks
Snapshot before major changes	Manual, before upgrades, redesigns or theme changes	90 days	Rolling back a failed upgrade, comparing against a quarterly review

Here’s the logic behind retention periods: accidental deletions and wrong edits usually surface within one to two weeks, so 14 days of incrementals is enough to catch them. Some corruption doesn’t happen all at once — a database failing slowly, spam content injected piece by piece — and by the time it shows up, weeks have often passed, so 8 weeks of full backups gives you a longer rollback window. The 90-day snapshots exist for major changes: if you find problems with a new version three months after a redesign, you can still go back and compare.

One boundary to spell out: backup frequency should follow how often your content changes, not a one-size-fits-all rule. If your site only updates once or twice a month, daily incrementals waste storage and maintenance effort — a weekly full backup plus a pre-change snapshot is enough. Conversely, if forms bring in inquiries every day and orders keep writing to the database, database backups can’t be less than once a day, and if you can manage it, run an incremental every six hours.

4. Off-site principle: a backup on the same machine is no backup at all

Off-site means three things must differ: a different server, a different account, and a different region from your site. A same-machine backup disappears along with your site the moment the host fails — a disk crash, a breach, a provider going out of business, or an account being suspended. In any of those cases, a same-machine backup cannot save you.

Where the backup lives	Host disk failure	Site breached	Main account stolen	What it means
Same server	Lost together	Lost or deleted together	Lost together	Unacceptable
Cloud drive or object storage under the same account	Unaffected	May be deleted	Lost together	Fails the test
Storage in the same region, different account	Unaffected	Security	Security	Acceptable
Storage in a different region, different account	Unaffected	Security	Security	Recommended

The “main account stolen” column is the one most people overlook. Once an attacker gains control of the host, the first thing they usually do is find and delete your backups so you cannot restore the site. That is why the account holding your backups must be completely separate from your site account, protected with two-factor authentication, and granted no permission on the site side to delete backups. Meet those three conditions and an attacker can fully control your site without ever touching your way back.

There is also a practical limit: cross-border access speed. When backup storage sits in another region, restoring can download several times slower than from the same region. A 300 MB backup takes a few minutes to download in the same region, but over an intercontinental link it can take half an hour or more. The way to balance this is to keep the primary copy in a nearby region and a cold copy in a distant one, then time your restore drills against the primary copy.

5. Backup tools and methods compared

Each of the four common methods has its own restore complexity. The key question when choosing is not how easy the backup is, but how smooth the restore is.

Method	Level of automation	Restore complexity	Applicable situation
Automatic backups from the host panel	High, runs on a schedule	Low, usually one-click restore	Managed hosting with no dedicated technical staff
Backup plugin	Medium-high, can be scheduled and pushed off-site	Medium, requires reinstalling in the restore environment and then importing	The standard approach for WordPress sites
Script plus object storage	High, runs as a scheduled task	Medium-high, requires command-line work	Teams with technical staff
Manual snapshot from the provider	Low, requested on demand	Low, performed by the provider	A safety net before migrations and upgrades

Two points to expand on. A one-click backup from the host panel is the least effort, but you must confirm the backup file can be downloaded locally — if the backup is locked inside the provider’s dashboard, you have effectively handed your restore capability to someone else, and if the provider runs into trouble you have no copy at all. The advantage of plugin backups is that they can push automatically to a cloud drive or object storage, taking care of the off-site requirement along the way; the drawback is that restoring depends on the plugin itself still working, and after serious damage to a site the plugin may already be broken. So at important milestones you still need a panel-level or manual snapshot underneath. The recommended combination of the four is: the plugin handles daily incremental backups and pushes them off-site, the host panel handles a weekly full backup as a fallback, and you take a manual snapshot before any major change.

6. Recovery Drills: Five Steps and How Long They Take

A drill isn’t clicking the restore button for show. You walk the whole process and time it. Here are the steps and the pass criteria.

Steps	Action	Pass criteria
1. Pull the backup	Download the most recent full backup from offsite storage	File size and checksum are correct, and it unzips cleanly
2. Set up a recovery environment	A temporary subdomain or local environment	The site starts with no environment errors
3. Import and restore	Restore the database and all files	You can log in to both the admin and the front end
4. Spot-check functionality	Submit a form, open a product page, check that images load	All core functions work
5. Compare the data	Check content and inquiry counts against what you recorded before the drill	No data is missing

Recommended frequency: a full drill every six months, scheduled during your slow season; a single-file recovery spot check every quarter, restoring one random post or image to verify. Record two things from each drill: total time, and where you got stuck. The step you got stuck on is your biggest risk in a real incident, so fix it on the spot instead of leaving it for the night everything breaks.

Site size	Data size	Typical full recovery time
Small business site	Database under 200 MB	30–60 minutes
Mid-sized site	200 MB to 2 GB	60–120 minutes
Image- and order-heavy site	Over 2 GB	About half a day

Prepare your fallback for during recovery ahead of time: put a static cached page at your maintenance path, state the expected recovery time and a backup contact (an alternate email or WhatsApp account), and post a temporary notice on your main domain. The point of that page isn’t technical. It’s to let customers who are visiting know you haven’t disappeared and can still be reached another way. If you need a backup and recovery plan designed around your site, you can Contact Us tell us about your setup.

7. Keeping Backups Safe and the Four Times You Must Back Up Manually

A backup file holds all your content, customer leads and database. It is sensitive data in its own right, and leaking it is just as much an incident.

Checklist	Requirement	Check frequency
Storage encryption	Backup files stored with server-side encryption or encrypted compression	Recheck when you change storage
Access permissions	Least privilege; deletions require a second confirmation	Quarterly
Two-factor on the account	Mandatory on the backup storage account	One-time, recheck when you change accounts
Failed-task alerts	Backup failures notify a specific person right away	Verify once a month after setup

Beyond your regular schedule, there are four moments when you must back up manually right away instead of waiting for the next scheduled run.

When you must back up manually	Why
Before a major version upgrade	Upgrades fail more than anything else, so you need a clear rollback point
Before changing the theme or launching a new feature	Changes overwrite files, and rolling back depends on a complete snapshot
Before bulk-editing content or importing data	Bulk operations can’t be undone one by one. A mistake is a mistake across the board
Before migrating hosts	Data inconsistencies during migration need a complete safety net

What these four moments have in common is that the action can’t be undone. Scheduled backups cover everyday risks; manual snapshots cover human error. Neither replaces the other. Your team should agree on one rule: whoever runs the upgrade or redesign hits the snapshot button first — as step one of the process, not an optional extra. For the full handoff in migration scenarios, see Migration and 301 Handoff.

FAQ

How often should you back up?

Follow your content update frequency — there’s no one-size-fits-all answer. If your database gets new inquiries or orders every day, once a day is the minimum. If your content updates weekly, a weekly full backup plus a snapshot before every change is enough. To decide, look at two numbers: how much new data you add per day, and how much data you can afford to lose. If losing a day’s inquiries is the most you can accept, your backup interval can’t exceed one day. If a week is acceptable, weekly works.

Where’s the safest place to store backups?

Object storage in a different region and under a different account, plus a local copy. What matters isn’t which provider you pick — it’s the rule of three differences: different server from your site, different account, different region. The worst setup is backups on the same host or under the same account; once an attacker gets access, the first thing they do is delete the backups. Always turn on two-factor authentication for the storage account, and make sure the site-side permissions don’t include deleting backups.

Plugin backups or hosting panel backups?

They complement each other — it’s not either/or. Hosting panel backups are the easiest to restore, but they often stay on the same machine, so you must confirm you can download them off-site regularly. Plugin backups make it easy to push automatically to cloud storage for off-site copies, but the plugin itself may fail if your site is badly damaged. The standard setup: the plugin pushes daily incremental backups off-site, the hosting panel keeps a weekly full backup, and you take a manual snapshot before any major change.

How do you actually run a restore drill, and will it affect the live site?

No — run the drill on a temporary subdomain or a local environment, never touching production. Five steps: download the most recent full backup, set up a restore environment, import and restore, spot-check forms and product page functions, and compare record counts against live data. Log how long each step takes. Run a full drill every six months and a single-file spot check every quarter. Whatever gets stuck during a drill is the most dangerous spot in a real incident — fix it on the spot instead of waiting for a disaster.

How big is a big database, and what should you watch out for when backing up?

The practical dividing lines are 200 MB and 2 GB. Sites under 200 MB are handled fine by most backup tools. Past 2 GB, plugin exports tend to time out, so you need to switch to command-line exports with split archives, and restore times stretch into the half-day range. Also watch for abnormal growth. A database that doubles in a month usually means a bloated log table or junk data being written in. Find out why first; don’t just keep backing up.

When moving hosts, what’s the safest way to bring backups along?

Three steps. First, run a full manual backup on the old host covering the database, files and server configuration. Second, download the backup files from the old host straight to your local machine. Don’t rely on host-to-host transfer as your only path. Third, once the new site is running and you’ve verified the content, decommission the old host, and keep the old data for at least two weeks. For DNS and 301 details during migration, see the separate article on site migration.

Final thoughts

Backups are the classic counterintuitive investment: invisible day to day, but they set the ceiling on your losses when something goes wrong. They don’t take advanced skills. They take three things happening on schedule: a rhythm that doesn’t get interrupted, copies that are genuinely off-site, and restores that have genuinely been tested. Miss any one of the three and no amount of backup logs is anything more than false comfort.

Here’s the order I’d suggest: first, store backups in a different account and a different region. Then check that all four backup categories are covered. Finally, put a restore drill on your calendar twice a year and log how long each one takes. Do these three things and most “we couldn’t recover it” disasters never happen.One line is all you need to remember: an untested backup is no backup at all.