The Backup You Have Never Restored Is Not a Backup, It Is a Hope

Two numbers, and neither one is how often it runs

NIST defines the Recovery Point Objective as the point in time you can recover data to, and the Recovery Time Objective as the maximum time a system can be unavailable before the impact is unacceptable. Backup frequency answers only the first.

Almost every business can tell you how often their backup runs. Very few can tell you how long a restore takes, and the second question is usually the expensive one. NIST separates them cleanly. The Recovery Point Objective represents the point in time, prior to a disruption or outage, to which business process data can be recovered given the most recent backup copy².

That is how much work you are prepared to lose. A nightly backup sets a worst case of nearly a full day: the orders, form submissions, bookings and content changes made since it ran. For a business taking a handful of inquiries a week that may be entirely acceptable. For one taking bookings continuously it is not, and the honest response is to change the frequency rather than to hope the timing is kind.

The other number is the one that gets skipped. NIST defines the Recovery Time Objective as the maximum amount of time a system resource can remain unavailable before there is an unacceptable impact on other resources and on supported business processes². In plain terms, how long can your site be down before the damage stops being about the website².

These are business decisions rather than technical ones, which is why they get avoided. Answering them takes a conversation and no software. Once answered, they tell you what your backup arrangement actually needs to do, and quite often reveal that the arrangement you are paying for was never designed to do it.

The attacker goes looking for the backups

CISA states that most ransomware actors attempt to find and then delete or encrypt any accessible backups, and names backup software itself as a target through stolen credentials and public exploits. A backup the compromised system can reach is a backup the attacker can reach.

This is the part that changes how the whole subject should be approached, and it comes straight from the joint guide. CISA says it is important that backups are maintained offline, because most ransomware actors attempt to find and subsequently delete or encrypt accessible backups¹. The backup is not a bystander to the incident. It is an objective within it.

Read your own setup against that sentence. If the backup lives on the same server as the site, it is reachable. If it sits in a cloud account that the same compromised credentials can open, it is reachable. If your host takes the backups and your host account is the thing that was breached, it is reachable. Plenty of arrangements that feel like backups fail this test.

The guide is also specific that the backup system itself is a target. Threat actors use credentials obtained in the environment to attempt to access backup solutions, and use publicly available exploits to target unpatched backup solutions¹. That last clause connects this directly to the patching argument: backup software is software, and an unpatched backup tool is an unlocked door to the thing protecting you.

CISA offers options with unusual candor about their downsides. It notes some cloud vendors offer immutable storage that protects data without a separate environment, but says to use immutable storage with caution because it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost¹. It also suggests considering multi-cloud for cloud-to-cloud backups, in case all accounts under one vendor are affected¹.

Testing means restoring, not checking a green tick

CISA asks you to regularly test the availability and integrity of backups in a disaster recovery scenario, and to test backup procedures regularly. That is a different activity from confirming the backup job completed, and it is where silent failures surface.

The instruction is short and most people have not followed it. CISA says to maintain offline, encrypted backups of critical data and to regularly test the availability and integrity of backups in a disaster recovery scenario, and separately, to test backup procedures on a regular basis¹. Note what is being tested: availability, integrity, and the procedure itself¹.

A dashboard showing a completed job tests none of those. Backups fail silently in ways that only appear on restore: a database exported while a write was in progress, a plugin directory quietly excluded by a default setting, an archive that has been truncating for months because storage filled up, credentials that expired so the last good copy is older than anybody thinks.

The procedure matters as much as the file. If restoring requires a login only one person has, a tool nobody has opened in two years, or a support ticket to a host that answers in business hours, then your recovery time is not the time the software takes. It is that plus everything else, discovered under pressure on a day when the site is down and the phone is ringing.

The useful version of this for a small business is one afternoon, once. Restore the site to a staging location and open it. Log in. Check the pages, the forms, the images and the database content. Write down how long the whole thing took from decision to working copy. That number is your real Recovery Time Objective, and it is almost always longer than people expect.

1. Decide how much work you can afford to lose. That sets backup frequency. It is a business answer, not a technical one.
2. Restore to a staging copy, today. Not a test of the job. An actual restore of an actual backup to somewhere you can open.
3. Time it end to end. From the decision to a working site. That figure is your genuine recovery time.
4. Check the restored copy properly. Pages, forms, images, database content, logins. Silent omissions only appear here.
5. Get one copy out of reach. Somewhere the site, its server and its credentials cannot touch.
6. Patch the backup tool as well. CISA names unpatched backup solutions as a target. It is software like anything else.

Where small business backups usually turn out to be thin

The three most common arrangements share one flaw: a single point of failure that the incident itself is likely to take out. Host-only backups, a single cloud account, and a backup plugin writing archives into the same filesystem all fail the same reachability test, and each fails it for a slightly different reason.

The most common arrangement is that the host takes backups, and that is the whole plan. It is genuinely better than nothing and it fails in a specific circumstance: when the problem is the host account, the billing lapse, or a compromise that reached the hosting control panel¹. It also tends to fail the ownership question we raised in who actually controls your domain, because the backups belong to an account somebody else administers.

The second is a backup plugin writing archives into the website filesystem. This is the arrangement CISA describes most directly, because the archives sit inside the thing being protected and an actor who reaches the site reaches them¹. It also has a mundane failure mode that is more common than any attack: the archives fill the disk, the job starts failing, and nobody notices until they need it.

The third is a single cloud storage account reached with credentials stored on the site or in the same password vault as everything else. It looks offsite and behaves as reachable, which is the distinction that matters. Whether a copy is safe is not about geography, it is about whether the credentials for it survive the incident, which is why this connects to who holds which credentials.

None of this requires an expensive product. It requires one copy that cannot be reached from the site or its administrator account, a known restore procedure that more than one person can run, and evidence that somebody has actually done it. CISA also suggests keeping and regularly updating golden images of critical systems so a rebuild does not start from nothing¹.

• If the site can reach the backup, so can whoever compromises the site.
• Host-only backups fail exactly when the host account is the problem.
• A backup nobody has restored is an untested assumption.
• Backup software needs patching like everything else.
• Recovery time includes finding the login and waiting for support.

What good looks like, without buying anything

Decide the two numbers, keep one copy out of reach, restore once to prove it works, and write down the procedure so somebody other than you can run it. Recovery should be prioritized by which services matter most, not by what is easiest to restore first.

The plan that follows from both documents is unglamorous and mostly free. Decide the two numbers with the business rather than the technician². Keep at least one copy where the site, its server and its administrator credentials cannot reach it. Restore it once so the claim is tested rather than assumed. Then write the procedure down somewhere that is not one person memory.

On the order of recovery, CISA is specific in a way worth borrowing. Its recovery guidance is to reconnect systems and restore data from offline, encrypted backups based on a prioritization of critical services¹. For a small business that means deciding in advance what has to work first: usually the ability to take inquiries and to be contactable, rather than the whole site at once.

One caution from the same guidance, because it is the mistake people make when they are in a hurry. Take care not to re-infect clean systems during recovery¹. Restoring a backup taken after a compromise began puts the problem straight back, which is why knowing when the backup was taken matters as much as having it, and why the detection question in what Google does when a site is hacked is part of the same problem.

And the boundary we keep to on every one of these. Backups do not prevent anything. They are what determines how bad a bad day gets, and the honest claim is a shorter outage and less lost work, not safety. That is part of what our website care work covers, alongside technical SEO services, and if you would like to see how your current setup stands first, our free SEO audit is a reasonable starting point.