# Your Website Backup Is Probably Untested

> Two numbers decide what a backup is worth, and neither is how often it runs. Here is what CISA says about backups, and the failure nobody tests for.

[Home](https://seoagencynaples.com/) / [Blog](https://seoagencynaples.com/blog/) / Technical SEO Site Protection
# The Backup You Have Never Restored Is Not a Backup, It Is a Hope
Almost every business has backups. Far fewer have ever restored one. Those are different things, and the difference only becomes visible on the day it matters most.

By [Jamie Kloncz](https://seoagencynaples.com/jamie-kloncz/), Founder and CEO, SEO Elite Agency ** 15 min read ** Published August 30, 2026

The pillar of advice under most website security is that you should keep backups, and it usually stops there. The harder questions are how much work you are prepared to lose, how long you can be offline while somebody puts it back, and whether the backup will still be there when you reach for it. Two federal documents answer those better than any vendor page.
NIST sets out the two numbers that actually define a recovery plan, and they are not backup frequency. CISA, in a guide written jointly with the FBI and the NSA, sets out something more uncomfortable: most ransomware actors deliberately go looking for your backups, and attempt to delete or encrypt the ones they can reach [1](#ref-1).
This guide covers the two numbers, why a backup your website can reach may not survive the incident it exists for, what testing actually means as distinct from checking a dashboard, and the places small business backups usually turn out to be thinner than assumed. Backups are a recovery control rather than a preventive one, and nothing here stops a compromise happening.

## 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 [2](#ref-2).
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 [2](#ref-2). In plain terms, how long can your site be down before the damage stops being about the website [2](#ref-2).
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.
Question The number What it is answered by
How much work can we lose? Recovery Point Objective How often the backup runs
How long can we be down? Recovery Time Objective How fast a restore actually completes
Will the backup survive the incident? Neither Whether it is reachable from the compromised system
Does the backup work at all? Neither Whether anybody has ever restored 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 [1](#ref-1). 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 [1](#ref-1). That last clause connects this directly to [the patching argument](https://seoagencynaples.com/blog/website-security-updates-patch-window/): 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 [1](#ref-1). It also suggests considering multi-cloud for cloud-to-cloud backups, in case all accounts under one vendor are affected [1](#ref-1).

Source: CISA #StopRansomware Guide and NIST SP 800-34 Rev. 1 Download SVG

## 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 [1](#ref-1). Note what is being tested: availability, integrity, and the procedure itself [1](#ref-1).
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.

- **Decide how much work you can afford to lose.** That sets backup frequency. It is a business answer, not a technical one.
- **Restore to a staging copy, today.** Not a test of the job. An actual restore of an actual backup to somewhere you can open.
- **Time it end to end.** From the decision to a working site. That figure is your genuine recovery time.
- **Check the restored copy properly.** Pages, forms, images, database content, logins. Silent omissions only appear here.
- **Get one copy out of reach.** Somewhere the site, its server and its credentials cannot touch.
- **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 [1](#ref-1). It also tends to fail the ownership question we raised in [who actually controls your domain](https://seoagencynaples.com/blog/who-owns-your-domain-name/), 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 [1](#ref-1). 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](https://seoagencynaples.com/blog/website-passwords-mfa-admin-access/).
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 [1](#ref-1).

- 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 [2](#ref-2). 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 [1](#ref-1). 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 [1](#ref-1). 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](https://seoagencynaples.com/blog/website-hacked-google-search-naples/) 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](https://seoagencynaples.com/technical-seo-services/), and if you would like to see how your current setup stands first, our [free SEO audit](https://seoagencynaples.com/free-seo-audit/) is a reasonable starting point.

Test yourself
## Is your backup actually a recovery plan?
Five questions from the joint CISA ransomware guide and the NIST contingency planning guide, both linked below.

- 1 Which number tells you how long your business can afford to be offline? Backup frequency Recovery Time Objective Recovery Point Objective Storage capacity **Answer:** Recovery Time Objective 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 business processes. It is a different question from how much data you would lose, and it is the one almost nobody measures. Most businesses can tell you how often their backup runs and cannot tell you how long a restore takes.
- 2 What does the Recovery Point Objective describe? How fast you recover The point in time you can recover data to How long backups are kept How many copies exist **Answer:** The point in time you can recover data to NIST describes the Recovery Point Objective as the point in time, prior to a disruption or outage, to which business process data can be recovered given the most recent backup copy. In plain terms it is how much work you are prepared to lose. A nightly backup means a worst case of nearly a full day of orders, form submissions and content, which for some businesses is fine and for others is not.
- 3 Why does CISA say backups should be kept offline? To save money Because most ransomware actors try to find and destroy reachable backups For legal reasons To improve restore speed **Answer:** Because most ransomware actors try to find and destroy reachable backups CISA states that it is important backups are maintained offline because most ransomware actors attempt to find and subsequently delete or encrypt accessible backups. This is the detail that undoes most small business setups. A backup stored on the same server, or in an account reachable with the same credentials, is reachable by whoever compromised that system in the first place.
- 4 Is your backup software itself a target? No, attackers only target the main site Yes, CISA names unpatched backup solutions specifically Only enterprise systems Only if it is self-hosted **Answer:** Yes, CISA names unpatched backup solutions specifically The guide states that threat actors use credentials obtained in the environment to attempt to access backup solutions, and that they also use publicly available exploits to target unpatched backup solutions. The backup system is part of your attack surface, not a safe place outside it, which means it needs the same patching discipline as everything else you run.
- 5 What does CISA say about testing backups? Check the job completed Regularly test availability and integrity in a disaster recovery scenario Test annually Testing is optional **Answer:** Regularly test availability and integrity in a disaster recovery scenario The wording asks you to regularly test the availability and integrity of backups in a disaster recovery scenario, and to test backup procedures on a regular basis. That is meaningfully stronger than confirming a green tick in a dashboard. It means restoring something and checking the result is usable, which is the step that reveals the backups that were silently incomplete for months.
Honest self-check. There is no sign-up, and nothing is stored.

Questions answered
## Straight answers to the common questions
The questions readers ask about this topic, answered directly. **No forms, no sales pitch.**

JAMIE KLONCZ · SEO AGENCY NAPLES ************** ONLINE
Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it.

← PREV NEXT → [FREE AUDIT →](https://seoagencynaples.com/free-seo-audit/)

- **How often should a small business website be backed up?** The honest answer is that frequency is decided by a business question rather than a technical rule. NIST describes the Recovery Point Objective as the point in time, prior to an outage, to which data can be recovered given the most recent backup copy. In plain terms it is how much work you are willing to lose. If your site takes bookings or orders continuously, a nightly backup means a worst case of nearly a full day of them. If it takes a handful of inquiries a week, nightly is comfortable. Decide the acceptable loss first, then set the frequency to match it, rather than accepting whatever the host happens to do.
- **Why does it matter whether backups are offline?** Because the backup is a target, not a bystander. CISA states that it is important to maintain backups offline, as most ransomware actors attempt to find and subsequently delete or encrypt accessible backups. The practical test is reachability rather than geography: if the backup sits on the same server as the site, or in a cloud account that the same compromised credentials open, or with a host whose control panel was the thing breached, then whoever got into the site can get into the backup. At least one copy needs to be somewhere the site, the server and the administrator login cannot reach.
- **Is a backup plugin enough?** It depends entirely on where it writes. A plugin that stores archives inside the website filesystem is the arrangement CISA describes most directly, because the copies sit inside the very thing being protected. It also carries a mundane failure that is more common than any attack: the archives gradually fill the available storage, the job starts failing, and nobody notices until the day it is needed. A plugin that pushes copies to separate storage with separate credentials is a different proposition. The question is not which plugin, it is whether the destination survives a compromise of the site.
- **What does testing a backup actually involve?** More than confirming the job completed, which is what most people mean by it. CISA asks you to regularly test the availability and integrity of backups in a disaster recovery scenario, and to test backup procedures on a regular basis. In practice that means restoring a backup to a staging location and opening it: checking pages, forms, images, logins and database content, because backups fail silently in ways that only appear on restore. It also means timing the whole exercise from decision to working copy, because that figure, and not the software speed, is your real recovery time.
- **Can attackers target the backup system itself?** Yes, and CISA names both routes. The guide states that threat actors use credentials obtained within the environment to attempt to access backup solutions, and that they also use publicly available exploits to target unpatched backup solutions. That second point is the one people miss: backup software is software, subject to the same vulnerability disclosure cycle as everything else, and an unpatched backup tool is a route into the system you are relying on for recovery. It should be on the same patching schedule as the site itself, not treated as infrastructure that sits safely outside the problem.
- **Is immutable cloud storage the answer?** It is an option, and CISA is unusually candid about its downsides. The guide notes that some cloud vendors offer immutable storage which can protect stored data without needing a separate environment, but says to use it with caution because it does not meet compliance criteria for certain regulations and because misconfiguration can impose significant cost. That is a more balanced description than most vendor material provides. For a small business the simpler goal is usually sufficient: one copy held under separate credentials, in a place the compromised system cannot reach, that somebody has actually restored from.
- **We were compromised. Can we just restore the backup?** Carefully, and with attention to timing. CISA advises reconnecting systems and restoring data from offline, encrypted backups based on a prioritization of critical services, and warns specifically to take care not to re-infect clean systems during recovery. The risk is restoring a copy taken after the compromise began, which puts the problem straight back and wastes the recovery. That is why knowing when the backup was made matters as much as having it, and why establishing when the compromise started is part of the work rather than a detail. Restoring blind is how businesses end up doing the whole exercise twice.

## References

- CISA, FBI, NSA and MS-ISAC. #StopRansomware Guide. version 3.0, publication October 2023, accessed 30 August 2026. [https://www.cisa.gov/resources-tools/resources/stopransomware-guide](https://www.cisa.gov/resources-tools/resources/stopransomware-guide)
- NIST. SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. published May 2010, updated November 2010, accessed 30 August 2026. [https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

Written by
## [Jamie Kloncz](https://seoagencynaples.com/jamie-kloncz/)
Founder and CEO, SEO Elite Agency
Jamie Kloncz is the founder and CEO of SEO Elite Agency, the firm behind SEO Agency Naples. An engineer who scaled his own plumbing business to 3 million dollars in revenue and led growth for over 200 teams, he built this agency on one principle: every SEO action must connect directly to revenue, not vanity metrics.
[More about Jamie →](https://seoagencynaples.com/jamie-kloncz/)

Free · No pressure
## See where your business actually stands
Start with a free audit of your rankings, Google Business Profile, technical health, and AI-search visibility, with a prioritized plan and an honest quote for your situation.
[Get your free audit](https://seoagencynaples.com/free-seo-audit/)

Keep reading
## Related guides
[Technical SEO The Federal Patch Deadline Is Now Three Days. When Was Your Website Last Updated? Read guide →](https://seoagencynaples.com/blog/website-security-updates-patch-window/)[Technical SEO Your Website Was Not Targeted, It Was Scanned: What Google Does When a Site Is Hacked Read guide →](https://seoagencynaples.com/blog/website-hacked-google-search-naples/)[Technical SEO The Password Rules Your Business Follows Are the Ones NIST Tells You to Stop Using Read guide →](https://seoagencynaples.com/blog/website-passwords-mfa-admin-access/)