Backups and Disaster Recovery: What to Test Before You Need It
Almost every business has backups. Considerably fewer have restores, and the difference between those two words is where the money is. A backup is a file that exists. A restore is a working site, with its database, its media, its configuration and its integrations, running again inside a time you can survive.
The gap between them is not theoretical. Published industry surveys put successful restore rates well below what owners expect: figures in the region of six in ten restore attempts producing the intended outcome, and only around a third of organisations actually recovering within the time they believed they could. Those numbers come from vendors selling backup products and deserve the usual scepticism about sampling, but the direction is consistent across sources and it matches what we find in audits.
Backups are now a target, not just a safety net
The assumption underneath most backup plans is that the backup will be there when the original is not. That assumption is a decade out of date.
Vendor incident data reports that the overwhelming majority of ransomware attacks now deliberately attempt to reach backup repositories before encrypting anything, and that a large share of those attempts succeed. The logic is obvious from the attacker’s side: an organisation with intact backups does not pay.
The practical consequence is one design change. At least one copy must be unreachable from the compromised system: offline, on a different account with different credentials, or immutable so that it cannot be deleted or overwritten even by someone holding valid administrator access. A backup stored on the same server, or in the same hosting account, is protection against mistakes and not against attacks.
The rule, updated
The old advice was three copies, two media types, one off-site. It is still the right foundation and it is no longer sufficient. The version worth adopting adds two things.
| Element | What it means | Common failure |
|---|---|---|
| Three copies | The live data plus two backups | One backup, treated as two because it runs nightly |
| Two different media or providers | Not both in the same account | Host snapshot and host backup, counted separately |
| One off-site | Different physical location and provider | Off-site in name, same provider in practice |
| One offline or immutable | Cannot be deleted by a compromised admin | Missing entirely on most small business setups |
| Zero errors on verification | A restore has been tested and produced a working system | Verification means “the job reported success” |
The last row is the one that turns a backup policy into a recovery capability, and it is the row almost universally skipped. Surveys suggest the large majority of disaster recovery setups have automated testing switched off entirely.
Two numbers that decide everything else
Before choosing tools, decide two things in business terms rather than technical ones.
How much data can you afford to lose? This sets the backup frequency. A brochure site that changes monthly can live with weekly backups. A shop taking fifty orders a day cannot lose a day, because those orders exist nowhere else and the customers are expecting delivery. Hourly database backups cost very little and are frequently absent from exactly the sites that need them.
How long can you be down? This sets the recovery method, and it is where expectations diverge from reality. Restoring a large media library from cold storage over a domestic connection is measured in hours regardless of how good your backup is. If four hours is the limit, the answer is a standby copy rather than a faster download.
Write both numbers down and check whether the current arrangement actually meets them. In most small businesses the honest answer is that nobody has ever asked, which is why the first restore is also the first measurement.
What actually needs backing up
Site backups routinely cover the files and the database and stop there, which leaves several things that are equally necessary to get running again.
- The database and the uploads, obviously, and together: a database restored against a mismatched media folder produces a site full of broken images.
- Configuration that lives outside the codebase. Server settings, redirect rules, cron jobs, environment variables. These are usually the reason a restored site behaves oddly.
- DNS records. Rarely backed up, occasionally lost, and a site that cannot be reached is down regardless of whether it works.
- Email, if it lives with the hosting. Mailboxes are frequently outside the backup scope and are often the most valuable data the business holds.
- Data held in third-party services. Form submissions, CRM records, review platforms. Your backup does not include somebody else’s system, and their export is your backup.
- The credentials to use any of it. A perfect backup with the recovery password stored only on the encrypted laptop is a well-known and entirely preventable failure.
Where those copies physically sit is a separate question with legal weight, particularly for anything containing personal data, and it is the practical core of where your website data actually lives.
Retention, and the awkward question about deletion
How long to keep backups is treated as a storage cost question and is also a legal one. Two considerations pull in opposite directions.
Longer retention protects against late discovery. Compromises and data corruption are frequently noticed weeks after they happen, and seven days of history is worthless against something found in week three. A reasonable shape for a small business is daily copies for a month, weekly for a quarter, monthly for a year.
Against that, backups contain personal data, and personal data has rules. When someone exercises a right to erasure, the copies in your backups are a genuine complication: regulators generally accept that restoring an entire archive to delete one record is disproportionate, provided you have a documented policy that the record will not be reinstated if a restore happens, and that the backup itself expires on a stated schedule. What is not acceptable is indefinite retention with no policy at all, which is what “we keep everything forever” amounts to.
Write the retention schedule down, state in the privacy documentation that backups exist and how long they live, and add a step to your deletion process that flags restored records for re-deletion. That is the whole obligation, and it is considerably cheaper than the alternative, as the process side of it is set out in handling data deletion requests.
The restore drill, in two hours
This is the whole article in one exercise, and almost nobody does it. Book two hours, tell whoever needs to know, and run it.
- Pick a date, not the latest backup. Restore from three weeks ago. Real incidents are discovered late, and the newest copy is often the compromised one.
- Restore to somewhere that is not production. A staging server or a local environment. The point is to prove the copy works, not to break the working site.
- Time it. From the decision to a functioning site. That number is your real recovery time, and it will be larger than the one in the contract.
- Use the site. Log in, place a test order, submit a form, check the media, check that scheduled tasks run. A homepage that loads is not a restored site.
- Write down what was missing. Something always is. Usually credentials, a configuration file, or a third-party integration that needs reconnecting.
Run this twice a year and after any significant change to the stack. The first one is uncomfortable and it is the cheapest incident you will ever have.
Where WordPress specifically bites
Three patterns recur on WordPress sites and each of them produces a backup that looks fine until it is needed.
Host-provided backups stored on the same account are the most common. They restore a deleted page perfectly and disappear along with everything else if the account is compromised or the provider has an incident. Treat them as convenience, not as protection.
Plugin backups writing into the uploads folder are the second. They are inside the web root, they can be reached by anything that reaches the site, and they inflate the next backup, which now contains the previous one.
Large media libraries are the third. Once uploads pass a few gigabytes, the full backup becomes slow enough that it quietly starts failing or being skipped, and nobody notices because the failure is a log entry. Separating media from database backups, with different frequencies, solves it. This sits alongside the rest of the baseline in how sites actually get compromised.
The runbook nobody writes until afterwards
A recovery plan is one page, and its value is that it exists on a day when nobody is thinking clearly. It answers five questions: who decides that this is an incident, who executes the restore, where the credentials are kept, in what order systems come back, and who tells customers.
Keep it somewhere reachable when the site and possibly the email are down. A printed copy sounds archaic and has saved more than one afternoon. And name a second person for every role, because incidents have a strong preference for holidays.
None of this is expensive. It is the part of a support arrangement that separates a plan that will work from an invoice that describes one.
The short version
Everyone has backups; the question is whether they restore, and industry figures put successful restores far below what owners assume. Backups are now an explicit target in ransomware attacks, so at least one copy must be offline or immutable and unreachable from a compromised administrator account. Update the old rule to three copies, two media, one off-site, one immutable, and zero errors verified by an actual restore. Decide two business numbers first: how much data you can lose, which sets frequency, and how long you can be down, which sets method. Back up more than files and database: configuration, DNS, email, third-party data and the credentials to use them. Then run a two-hour restore drill from a three-week-old copy to a non-production environment, time it, and use the restored site properly. Whatever is missing will surface there, which is the cheapest place for it to surface.
