Backups: The One Thing That Will Save You, and Why Most People Set Them Up Wrong

The phrase “we have backups” is doing a lot of work in too many incident reports. It usually means one of three things: there is a snapshot somewhere, we think; the second drive in the server is mirroring the first; or the cloud folder duplicates itself, which we checked once. None of these are the same as having a backup you can restore in the time you need, from a credential the attacker does not have, with the data the attacker did not also encrypt.

The reason this matters is that backups are the single most reliable determinant of whether a ransomware event, a cloud outage, a vendor compromise, or a good old fashioned disk failure becomes an incident or a catastrophe. Most organizations are not catastrophically under funded on security. They are catastrophically under tested on recovery. This article is about closing that gap.

What a backup actually is, and what it is not

A backup is an independent copy of data that you can use to restore service when the primary system is gone. Each of those words matters.

Independent. The backup cannot share an identity, an account, a network, a hypervisor, a cloud account, or a domain with the system it backs up. If the attacker can reach the backup by reaching the production system, the backup is not a backup. It is a second copy on the same blast radius.

Copy. A snapshot of a running system is not a copy if the snapshot is taken from inside the system being backed up. A replication target that is online and reachable is not a copy if it is also encrypted with the same keys. A RAID array is not a copy. A RAID protects you from a disk failure. It does not protect you from ransomware, an attacker, a misconfigured delete, or a cloud account compromise.

Restore. A backup that has never been restored is a theory. The only proof that you have a backup is that you have restored it. This serves as the part most organizations skip, and the part that fails them when the incident arrives.

The 3-2-1 model, and what extends it

The traditional rule is three copies, on two different media, with one offsite. It is older than most of the readers of this article and it is still useful. It is also not enough on its own.

The reason 3-2-1 is necessary is that any single copy can be lost. Disk failures, accidental deletion, fire, ransomware, account takeover, vendor outages: any of these can take one copy, and a disturbing number of them can take two at once. Three copies on two media with one offsite gives you a way to recover from a single point of failure and a second way to recover from a regional failure.

What 3-2-1 does not do, on its own, is protect you from a sophisticated attacker. A modern attacker, with time and a foothold, will hunt for backups. They will look for the backup server, the backup credentials, the cloud sync folder, the snapshot repository, and the management console. They will look for the service account that the backup software uses to write to object storage. They will look for the cloud native snapshot target. If those things are reachable from the same identity that the attacker has compromised, the attacker will find them. The 3-2-1 rule counts copies. It does not count independence.

The extension the industry has largely settled on is some version of 3-2-1-1-0. Three copies, two media, one offsite, one immutable or offline, zero errors on restore verification. The immutable or offline copy sits as the one that defends against the attacker who has been inside your environment for weeks. Immutable means the backup cannot be modified or deleted within its retention window, even by an administrator. Offline means the copy is physically or logically disconnected from the production environment for most of its life. Either is sufficient. Both is better.

None of this replaces the basics of the NIST Cybersecurity Framework or the CISA guidance on ransomware preparedness, but it runs as the part most often missing when an organization fails to recover.

Recovery Point Objective, Recovery Time Objective, scope

Two numbers drive almost every backup decision, and most organizations have neither.

Recovery Point Objective (RPO). The maximum amount of data you are willing to lose, measured in time. If your last successful backup was 6 hours ago and your RPO is 1 hour, you have a problem that the next incident will expose. RPO is set by the business. It is enforced by backup frequency.

Recovery Time Objective (RTO). The maximum amount of time you are willing to be down after a disaster, before service is back. RTO is set by the business. It is enforced by the speed of restore, the runbooks, the network, and the people on call.

If you do not know your RPO and RTO for each system, you cannot meaningfully answer the question “do we have backups.” You have data being copied somewhere. You do not know whether that copy is good enough, fast enough, or tested enough to satisfy the business when it is asking why the customer portal is down.

Scope serves as the third thing the conversation usually skips. Most environments are not one system. They are a database, an application server, a file share, a configuration store, a key vault, a queue, a CDN configuration, a DNS record, and a small set of credentials that tie the whole thing together. A backup that covers the database but not the secrets used by the application is not a backup of the system. It is a backup of one component. A useful backup strategy covers the whole system, end to end, and is tested as a system, end to end.

The backup concepts that cause the most failures

Replication is not a backup. Replication is real time. It is also the same data, written to a target that is online, reachable, and usually authenticated with the same identity that runs production. A replication target is excellent for fast failover. It is not, by itself, protection against ransomware, deletion, or credential compromise.

Synchronization is not a backup. A cloud sync folder gives you the file on another machine. It also gives the attacker the file on another machine, the moment they touch the account. It is a useful feature. It is not a backup.

RAID is not a backup. RAID protects you from a disk failure. It does not protect you from the things that actually destroy data: ransomware, accidental deletion, configuration error, fire, theft, or a compromised admin account.

Version history is closer to a backup, but check the scope. Most cloud file services keep a version history. It is genuinely useful. It is also usually scoped to a single account, which means a compromised account can often be used to delete the version history. CISA’s #StopRansomware guidance is explicit that cloud only retention does not satisfy the offsite, immutable, or independent requirements.

SaaS data is your data, and the SaaS backup is your problem. Most SaaS providers (collaboration, file storage, ticketing, code hosting, customer relationship management) operate on a shared responsibility model. They back up their infrastructure. They do not back up your data on a schedule you control, to a target you control, with a retention window you control. The vendor may be able to recover from an infrastructure failure. The vendor is generally not going to recover from your employee accidentally deleting the production project. You need a SaaS aware backup product for the systems you care about, and you need to test the restore from it.

Credential separation and immutability

Two controls separate a working backup from a paper backup.

Credential separation. The identity used to write backups must not be the identity used to administer production. It must not be the identity that runs the workloads being backed up. It must not be the identity that owns the object storage. It should be an isolated service account with the minimum permissions needed to write to the backup target, stored in a vault that requires out of band approval to access. If the production account is compromised, the backup account should not be.

Immutability. The backup target should not be deletable by the account that wrote to it, for the retention window you care about. Modern object stores support this with object lock. Backup products support it with their own WORM (write once, read many) modes. The point is that even an administrator with the credential should not be able to quietly destroy the last 30 days of backups. The attacker should not be able to either.

A backup you have never restored is only a theory

Restore testing amounts to the part the industry most consistently skips. It amounts to the part that fails in the worst incidents. A test does not need to be elaborate. It needs to be honest. The honest version of a restore test runs the full sequence, in an isolated environment, with the people who would actually have to do it at 2 a.m. when the production system is down.

A realistic restore test exercises these scenarios at least once a year, and again after any major change.

1. One ordinary file. A user reports a missing document. Can you restore it, with the right permissions, in the time the user will tolerate?
2. A whole folder. A team has lost a project folder. Can you restore the folder, with the right ownership and the right timestamps, on a clean machine?
3. A database. The application is broken. Can you restore the database to a clean instance, with the right schema, the right indexes, the right credentials, in the time the business will tolerate?
4. A whole application. The environment is gone. Can you stand up the application, the data, the configuration, the secrets, and the network in a clean account, in the time the business will tolerate? This becomes the test that exposes the missing scope.
5. Permissions and encryption keys. After a restore, can a real user actually log in and see the right data? A common restore failure is “the data is back but encrypted with a key we cannot find” or “the data is back but owned by root and nobody can read it.”
6. Measure the time. Restore testing without a timer is theatre. Time the whole sequence, from “we need to restore” to “a real user can do their job.” Compare to your RTO. If the numbers do not match, you do not have a backup that meets the business requirement.
7. Record what failed. Every restore test produces a list of things that did not work. File the list. Fix the top three before the next test. Repeat.

None of this is exotic. It is what every mature operations team has been doing for decades. Most organizations have not been doing it, which is why most organizations find out their backups do not work during the incident that the backups were supposed to be there for.

What good looks like, in checklist form

The four buckets below cover most of what an honest backup program needs. If you cannot answer yes to most of them, the gap is not theoretical.

This week

• List every system that runs in production. Include databases, file shares, configuration stores, key vaults, identity providers, queues, and DNS records.
• For each, identify what is being backed up, where it is being backed up to, and what identity has access to the backup.
• Confirm at least one copy is offline, immutable, or stored under a credential the production team cannot reach.
• Test Restore a single file. Time it.

This month

• Test Restore a whole folder, a whole database, and a whole application. Time each one.
• Compare the times to the documented RPO and RTO. Document the gap.
• Review the backup credentials. Move them to a vault, separated from production, with audit logging.
• Confirm the backup target is configured for immutability (object lock, WORM, or offline) for the retention window you need.

Every quarter

• Run a full disaster recovery exercise against one production system. Include the people, the runbooks, and the communication plan.
• Review the backup scope. Add anything that was added in production during the last quarter and is not in the backup.
• Review the retention. Confirm it matches the legal, regulatory, and business requirements for each system.
• Verify failed backup jobs. A backup that failed for three months is not a backup.

After any major system change

• Update the backup scope to cover anything new.
• Run a test restore of the changed system before declaring the change complete.
• Update the runbooks.

The point

Backups are the most unglamorous part of security, and they are the part that decides whether an incident ends with a postmortem or with a going-out-of-business announcement. They are also the part most likely to be assumed, untested, and quietly wrong. The fix is not a new product. The fix is scope, independence, immutability, separation, and the discipline to actually restore what you have, on a schedule, in conditions that resemble the real one.

Do that, and the next time someone says “we have backups,” they will be right.

Archive note: This article was added retrospectively to the Human Required 2026 archive. Its research and links were reviewed when it was added.

The bottom line

The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.