Is Your Backup a Backup, or Just a Copy in the Same Place?

The plugin says the backup completed. The archive is sitting in a folder inside the web root, on the same disk as the site it protects, writable by the same process that serves the pages. There is a green tick in the dashboard and somebody has ticked a box on a checklist.

That is a copy. It is not a backup. A backup strategy is three properties rather than a product: separation, a restore somebody has actually performed, and a retention window long enough to reach past the damage. A copy that fails any one of them keeps producing green ticks right up until the morning it is needed.

The failures we find are never exotic. The copy lived where the original lived. Nobody had ever restored one. The retention window was shorter than the time it took anyone to notice the problem. Each of those is boring, each is cheap to fix in advance, and each is discovered at the single worst moment available.

So this is a piece about proving a backup rather than buying one, and it ends with a drill you can run before the end of the month.

What turns a copy into a backup

Three properties, and the whole argument hangs off them. They are not a maturity ladder to climb over three years. A copy that has one of them and not the other two is closer to a hostage than an insurance policy.

• Separation. The copy survives the loss of the original, including the loss of the server, the hosting account, and the credentials that created it.
• Restorability. Somebody has restored from this copy recently, onto something other than the machine it came from, and the result worked without improvisation.
• Retention. Copies reach back further than the time it takes you to notice something has gone wrong, which is usually longer than anyone estimates.

Everything below is the detail behind those three. It is worth being blunt about where this sits: backups are not a feature you buy once, they are part of keeping a site alive over years, and they decay quietly whenever nobody is checking them.

The separation requirement

Separate from the server

A backup does not live on the machine it is backing up. That one sentence eliminates most of what we are shown. Archives inside the web root are the common case, and they are worse than useless, because they are also downloadable by anybody who guesses the path.

Host snapshots are genuinely useful and are not separation. A snapshot lives inside the account it protects, which means a billing dispute, a suspended account or a compromised control panel takes both at once. On WordPress this is worth checking today, because the default arrangement in many installs writes archives back into the content directory. The WordPress documentation on backups is explicit that a database dump alone is not the whole site, and that is the part teams most often get half right.

Separate from the credentials

This is the rule almost everyone misses. If the site can delete its own backups, so can anybody who controls the site. The account that writes the copy must not be the account that can destroy it. Append-only credentials, a separate storage account, object versioning, or a retention lock that refuses deletion for a fixed period: any of these turns the copy from a target into an asset.

Push the same question up a level. If one compromised administrator account reaches the site, the DNS, the email domain and the backup storage, you do not have four systems, you have one failure domain wearing four hats. This is the first thing to map when you inherit an estate, and it pairs with the wider problem of securing a website you did not build, where nobody remembers what has access to what.

Restore testing, which is the actual product

An untested backup is a hypothesis. The archive can be complete, recent, separated and encrypted, and still fail to produce a working site, because the parts that make a site run are rarely all inside the archive.

A backup is a claim about the future. A restore is the only evidence anybody will accept once the claim is being tested.

What a restore actually has to reassemble

• The database, with the character set and collation it was created with, not the ones the new server defaults to.
• Uploaded media, which on a mature site is usually larger than everything else combined and is often excluded to keep the archive small.
• Configuration holding keys, salts and connection strings, which people frequently leave out of a backup on purpose and then cannot reproduce.
• Environment variables and third-party secrets, which almost never live in the archive and sit in one person’s password manager.
• DNS records and certificates, which are in no backup at all and will decide whether the restored site is reachable.
• Scheduled jobs, queue workers and search indexes, all invisible until something silently stops happening.

Notice how much of that list is not inside the file you are paying to store. Which is why the restore runbook matters more than the backup tool: a short document saying where each piece comes from and in what order. It belongs with the rest of the material you would need when handing a codebase to someone who was not there, and it is tested the same way, by making somebody else use it.

For an application rather than a brochure site, add the ordering problem. A database restored to one point in time and a file store restored to another produces records referencing files that do not exist, and the errors surface days later in places nobody connects to the restore. Anything with real state, which is most web application work, needs the two to be consistent with each other rather than merely recent.

Retention, and the damage you find late

The most expensive failure is not deletion. It is corruption nobody noticed. A migration that dropped a column. An import that overwrote product descriptions with the wrong language. An injection that has been quietly editing rows for weeks. All of them replicate into every backup taken afterwards, so a schedule keeping a handful of daily copies gives you a handful of copies of the damage.

Retention is therefore sized against your discovery lag, not against storage cost. The usual shape works: daily copies for a short window, weekly copies for a longer one, monthly copies for a year. What matters is that somebody has asked how long a subtle problem could go unnoticed on this particular site, and then kept something older than that answer.

Retention has a second edge, and it cuts the other way. Backups hold personal data, which makes the window a processing decision with obligations attached rather than a technical preference. Write it down, be able to explain why it is that length, and make sure a restore does not resurrect records somebody asked you to erase. Your processors carry obligations here too, which is part of what a data processing agreement should say before anyone signs it.

What a ransomware case demands that a disk failure does not

A disk failure is indifferent to your backups. An attacker is not. Modern intrusions look for the backup system early, because a business with working backups does not pay. That single difference is what separates a copy from a backup, and it raises three requirements a hardware-failure plan never surfaces.

First, at least one copy that no live credential can delete: immutable, offline, or held by an account the compromised systems cannot reach. Second, the credentials needed during recovery stored somewhere that does not depend on the systems being recovered, because a password manager behind a single sign-on that is itself compromised is not available on the day. Third, an inventory saying what the site actually consists of, since recovery under pressure is a poor time to discover a service nobody documented.

And there is a decision to make before the day arrives: what clean means. Restoring to the night before the encryption also restores whatever let them in, along with whatever they left behind. A restore without a root cause is a countdown rather than a recovery, so the forensic question and the restore question run in parallel instead of in sequence.

Whatever that investigation turns up has to be written in a form somebody can act on months later. A product like Prooflin resolves findings, severities, priorities and recommendations into reviewable reports for exactly this reason, and our parent company has set out what a finding has to contain to be useful. A recovery that produces no written findings tends to be followed by the same incident.

One more thing changes with the type of site. On a shop, the recovery point matters more than the recovery time: an hour of lost orders is an hour of customers who paid and do not exist in your system, and reconciling that by hand is worse than the outage was. Anyone running e-commerce infrastructure should be backing up order data on a different rhythm from the rest of the site.

The drill you can run this month

Book two hours. Say clearly that this is a test of the documentation and not of the person doing the restore, because a drill people are scored on becomes a rehearsal and stops telling you anything true.

1. Pick an older date, not the newest copy. Ask for the site as it stood two weeks ago. Restoring last night proves the least interesting case.
2. Restore somewhere new. A fresh server, a container, a local environment. Never over the live site, and never onto the machine the archive came from.
3. Use only the written runbook. Nobody may ask the person who set it up. If that rule makes the drill impossible, you have your first finding already.
4. Load three pages. One that needs the database, one that needs an uploaded image, one behind a login. Media and authentication are where restores usually come apart.
5. Complete one real action. Submit a form, place a test order, trigger a transactional email. This proves the third-party configuration survived, which the archive alone never does.
6. Write down every question anybody had to ask. Each one is a gap in the runbook, and each is cheap to close today.
7. Record the two figures that matter. How much data was lost, and how long the restore took. Measured, not promised. Those are your real recovery objectives whatever the policy document claims.

If the drill fails, that is the right outcome for a quiet Tuesday and the worst outcome for the day you need it. Failure on a scheduled afternoon costs two hours and a slightly awkward conversation. Nobody has ever regretted running one.

What backups do not cover

Backups are a recovery control and nothing else. They prevent no intrusion, block no vulnerable dependency and detect no compromise. A team with excellent backups and no patching schedule will restore the same site repeatedly and learn nothing each time. Recovery sits alongside identification, protection and detection rather than substituting for any of them.

They also cost real money and, more to the point, real attention. Storage is the cheap part. The drill is the expensive part, because it uses people for an afternoon and produces nothing visible. That is precisely why it gets dropped, and precisely why it belongs as a named line in what it costs to maintain the thing you built rather than as goodwill from whoever has a free Friday.

Here is the honest limit. For a small site whose content lives in a repository and whose deployment is reproducible from that repository, most of this advice is heavier than the asset deserves. The site is the code plus a build, and the only irreplaceable thing is the form submissions. The picture changes completely once content has been pasted into a page builder and the layout lives in database rows, which is one of the quieter reasons a theme becomes a liability: it makes the site unreproducible without a database restore.

Where we would start this week

Answer three questions in writing, today, before touching any tooling. Where does the copy physically live. Which credential can delete it. When did somebody last restore from it, and onto what. If any answer is a shrug, you have found the work, and it is smaller than the answer you are dreading.

Then run the drill once, badly, with whatever exists now. The first attempt is meant to be untidy. Its output is a list of gaps, and a list of gaps is a plan you can cost, argue for and finish. Fix the separation problem first, because it is usually a configuration change rather than a project, then write the runbook that the second drill will test.

After that it is a rhythm rather than an initiative: restore on a schedule, keep the runbook current, and treat every question asked during a drill as a defect. If you would rather have somebody run the first drill alongside you and write up what it found, tell us what you are running and where the copies are supposed to be going.