1 Overview
Snapshots and backups are often treated as interchangeable safety nets, but they answer different questions. A snapshot captures the state of a data set at a moment in time, usually within the same storage system that holds the live data. It is fast to create and fast to roll back, which makes it excellent for short-term recovery from mistakes such as a bad patch, an accidental deletion, or a failed application upgrade. A backup, by contrast, is an independent copy of data written to separate storage, ideally on different media and in a different location. Its purpose is to survive the loss of the primary system, not merely to rewind it.
The confusion matters because a recovery plan built only on snapshots can look healthy in routine tests while failing in a real disaster. If the storage array, its credentials, or the site itself is lost, snapshots disappear with the primary data. A workable plan uses snapshots for speed and backups for durability, and it defines clearly which events each mechanism is expected to handle.
This article explains what each approach protects against, how to choose a strategy, how the 3-2-1 rule applies in practice, why restore testing is the only meaningful proof, and how offsite copies and encryption fit together. The goal is a recovery plan that survives the failure modes you are most likely to face, not just the ones that are convenient to test.
2 What you are actually protecting against
Recovery planning starts with a candid list of failure modes. Logical errors are the most common: a user deletes the wrong file, an application corrupts a record, a script drops a table, or a bad deployment writes invalid data. These events damage data while the underlying storage remains healthy, so a recent snapshot or backup can restore service quickly. Snapshots are especially effective here because the rollback is local and immediate.
Hardware and platform failures are different. A disk, controller, or storage node can fail, and while redundancy may mask a single failure, correlated failures or a botched repair can take the whole array offline. Virtualization adds another layer: a hypervisor bug, a misconfigured cluster, or a failed migration can make virtual machines unreachable even when their disks are intact. Backups on separate storage are the reliable answer because they do not depend on the failed platform.
Then there are site-level and human threats. Fire, flood, power loss, theft, ransomware, and malicious insiders can destroy or encrypt both primary data and any snapshots stored alongside it. Ransomware in particular targets reachable copies, including mounted snapshots and connected backup targets. A plan that assumes the primary site and its credentials remain trustworthy is not a disaster recovery plan. It is a convenience feature. The practical response is to separate copies by media, location, and access path so that no single event can remove all of them.
3 Choosing a backup strategy
A sound strategy begins with two business questions: how much data can you afford to lose, and how long can you afford to be without service? These become the recovery point objective and recovery time objective. They should be set by the business, not by the storage team, because they determine cost. A recovery point objective of minutes demands frequent capture and often snapshots or continuous replication. A recovery point objective of hours allows scheduled backups. A recovery time objective of minutes requires warm standby systems, while hours or days can tolerate restoring from media.
Next, match the mechanism to the job. Use snapshots for fast rollback of recent changes and for creating consistent points from which backups can run. Use full backups periodically to establish a complete baseline, and incremental or differential backups between them to reduce time and storage. Keep the chain manageable: long chains of dependent incrementals increase the chance that one damaged segment breaks the whole restore. Periodic full backups or synthetic fulls reset the chain and simplify recovery.
Finally, decide what is backed up and at what granularity. Image-level backups restore whole systems quickly but can be large. File-level backups allow granular recovery but may be slower for full-system rebuilds. Database backups need application-aware methods to capture consistent state. Document the choices, the schedule, and the retention for each data class, and revisit them as systems change. A strategy that is not written down and reviewed tends to drift away from the data it was meant to protect.
4 The 3-2-1 rule in practice
The 3-2-1 rule states that you should keep at least three copies of your data, on two different media types, with one copy offsite. It is a simple heuristic, not a guarantee, but it forces useful separation. The first copy is the live data. The second is a local backup or snapshot on separate storage, which enables fast recovery from logical errors and local hardware failure. The third is an offsite or isolated copy that survives loss of the primary site.
In practice, the two media types might be a disk-based backup appliance and tape, or local disk plus object storage in another region. The point is to avoid a single failure mode taking out every copy. If all copies live on the same array, the same firmware bug, power event, or ransomware infection can reach them. If all copies share the same credentials, one compromised account can delete them. Separation of media, location, and access path is what gives the rule its value.
The offsite copy deserves special attention. It should be written in a format that can be restored without the original backup server, and it should be protected from deletion by ordinary production credentials. Many teams add an immutable or air-gapped copy so that even an administrator account cannot erase it during a retention window. Test that the offsite copy is complete and readable, not merely present. A copy you cannot restore is not a copy; it is an assumption. The 3-2-1 rule works when each copy is independently recoverable.
5 Restore is the real test
A backup job that reports success proves only that data was written. It does not prove that the data can be read, that the application can start from it, or that the recovery meets the required time. The only meaningful test is a restore, performed on a schedule, into an environment that resembles production. Start with small, frequent tests: recover a single file, a mailbox, or a database table and verify its contents. Then run larger exercises: rebuild a virtual machine, bring up an application stack, and confirm that dependent services reconnect correctly.
Measure the restore while you do it. Record how long it takes to locate the backup, transfer the data, apply incremental segments, and return the service to users. Compare that against the recovery time objective. If the measured time exceeds the objective, the plan is not ready, regardless of how many successful backup jobs appear in the console. Also test partial failures: a missing incremental, a corrupted segment, a tape that will not read, or an encryption key that is unavailable. These are the conditions that turn a routine restore into an incident.
Document the results and fix what fails. Common findings include undocumented dependencies, missing credentials, outdated runbooks, and backup chains so long that a single bad segment blocks recovery. Stress testing restores also exposes whether snapshots were mistaken for backups. If the only recoverable copy is a snapshot on the failed system, the exercise will reveal it before a real disaster does.
6 Offsite and encryption
Offsite storage protects against events that destroy or deny access to the primary site, including fire, flood, theft, power loss, and regional outages. The offsite copy should be geographically separated enough that a single event cannot affect both locations, and it should be reachable through a path that does not depend on the primary site's network or credentials. For many organizations, object storage in a second region or a managed vault serves this role; for others, physical media shipped to a secure facility remains appropriate. Whatever the medium, the offsite copy must be verified by periodic restore, not just by transfer logs.
Encryption is essential for any copy that leaves controlled premises, and it is good practice even for local copies. Encrypt data at rest on backup media and in transit between sites. Use strong, well-reviewed algorithms and manage keys separately from the encrypted data, because a key stored beside its backup offers little protection. Plan for key rotation, escrow, and recovery: if the key is lost, the backup is lost. Access controls should limit who can read, delete, or alter backups, and audit logs should record those actions.
Encryption also interacts with ransomware defense. An encrypted, immutable offsite copy cannot be quietly rewritten by an attacker who compromises production credentials. Combine encryption with retention locks or air gaps so that a deletion request cannot propagate to every copy. The aim is a recovery path that remains available even when the primary environment is untrusted. Offsite and encryption together turn a local backup habit into a resilient recovery capability.
7 Frequently asked questions
Are snapshots a replacement for backups? No. Snapshots are fast, local point-in-time copies that depend on the same storage system as the live data. They are ideal for short-term rollback, but they do not survive loss of the array, the site, or the credentials that control them. Backups are independent copies on separate media and locations. Use snapshots for speed and backups for durability, and make sure a snapshot is never the only recoverable copy.
How often should backups run? Frequency follows the recovery point objective. If losing an hour of data is unacceptable, back up at least hourly, often with continuous or near-continuous methods. If losing a day is tolerable, nightly backups may suffice. Retention follows business, legal, and compliance needs, and it should be documented per data class. More frequent backups reduce potential data loss but increase storage, bandwidth, and management cost.
How do I know my backups work? Restore them. Schedule regular restore tests, from single files to full application stacks, and measure the time against your recovery time objective. Verify offsite copies independently, confirm that encryption keys are available, and keep runbooks current. A backup that has never been restored is an untested assumption. Stress testing restores and encryption together is the most reliable way to find gaps before an incident does.