1 Overview
A snapshot is a point-in-time view of a storage volume, usually created in seconds and kept on the same system as the data it describes. That speed and convenience make snapshots genuinely useful for undoing a bad change, rolling back a failed upgrade, or cloning a volume for a test. The problem starts when a snapshot is treated as the last line of defense. Because it lives on or beside the primary storage, it shares the failure modes of that storage: a corrupted filesystem, a deleted volume, a broken replication link, or a compromised administrator account can take the snapshot with it.
A backup is a separate copy of data, stored in a different place, under different credentials, and recoverable without the original system being healthy. The distinction is not about technology labels but about independence. If the only way to read a copy is through the same array, hypervisor, or account that produced it, you have a recovery shortcut, not a backup. This article explains what snapshots actually protect against, how to build a real backup strategy around the 3-2-1 rule, why restore testing is the only proof that matters, and how offsite storage and encryption fit together.
2 What you are actually protecting against
Data loss rarely comes from a single dramatic event. More often it arrives through a chain of small failures: an accidental deletion that propagates through replication, a ransomware process that encrypts mounted volumes and then targets the snapshots it can reach, a storage controller that fails and takes its snapshot pool offline, or a software bug that writes bad data for hours before anyone notices. Each scenario has a different recovery shape, and snapshots only address some of them.
Snapshots are strong against logical mistakes that are noticed quickly, such as a dropped table or a bad configuration push, because the previous state is still on the same device. They are weak against anything that damages the underlying storage, the management plane, or the credentials used to reach them. Ransomware operators know this and deliberately hunt for snapshot repositories and backup catalogs. A power event, firmware fault, or failed array can render both the live data and its snapshots unreadable at the same moment.
Real backups assume the primary system may be gone, hostile, or lying about its own health. That assumption drives every design choice: separate storage, separate credentials, versioned copies, and a tested path to rebuild service somewhere else. The goal is not to duplicate snapshots but to survive their loss.
3 Choosing a backup strategy
Start with recovery objectives rather than products. A recovery point objective describes how much data you can afford to lose, measured in time; a recovery time objective describes how long the business can tolerate an outage. These two numbers decide how often you copy data, how many versions you keep, and whether you need continuous replication or a nightly job. Write them down, get them agreed by the people who own the service, and revisit them when the service changes.
Next, match the method to the data. Databases often need transaction-consistent backups or log shipping so the restored copy is not torn. Virtual machines can be captured at the image level, but application-aware processing matters when the guest runs a database or directory service. File shares may tolerate simpler versioned copies. In every case, keep the backup independent of the snapshot layer: a snapshot can serve as a staging point for a backup job, but the resulting copy must be written somewhere the primary system cannot reach or delete.
Finally, decide retention deliberately. Keeping every hourly copy forever is expensive and slow to search; keeping only the last copy is fragile. A common pattern is frequent short-term restore points, fewer weekly copies, and long-lived monthly or annual archives for legal or historical needs. Document which copy you would use for which failure, and make sure the oldest copy you promise is actually restorable.
4 The 3-2-1 rule in practice
The 3-2-1 rule says keep at least three copies of important data, on two different types of media or storage systems, with one copy offsite. It is popular because it is simple and because it forces independence at three levels. Three copies means the original plus two backups, so a single failed backup does not leave you exposed. Two media types means a controller or firmware fault in one storage technology does not silently corrupt every copy. One offsite copy means a fire, flood, theft, or regional outage cannot destroy all of them together.
In practice, a workable layout might be the live data on primary storage, a local backup on separate hardware for fast restores, and an offsite copy in another region or on encrypted removable media stored elsewhere. The offsite copy does not have to be a full mirror; it can be a compressed, deduplicated, or archival form as long as it can be restored within your recovery time objective. What matters is that the copies do not share a single point of failure, including shared credentials and shared administrative access.
Modern practice often extends the rule to 3-2-1-1-0: an additional immutable or offline copy, and zero errors verified by testing. Immutability, whether through write-once storage, object lock, or air-gapped media, prevents an attacker or a mistaken administrator from deleting the backups. The final zero is the hardest and most important part, because it can only be earned by restoring.
5 Restore is the real test
A backup that has never been restored is a hypothesis. Backups fail for mundane reasons: a job that reported success but skipped a locked file, an encryption key that was rotated and not escrowed, a tape or object that aged out earlier than expected, a catalog that lost track of where the data lives. None of these problems appear in a green status dashboard. They appear the first time someone tries to recover under pressure.
Build a restore testing habit that matches the value of the data. At minimum, restore individual files or mailboxes on a regular schedule and confirm the contents open correctly. Periodically perform a fuller exercise: rebuild a server or application from backups in an isolated environment, then verify that it starts, authenticates, and serves real queries. Time each step and compare the result with your recovery time objective. If the measured restore takes longer than promised, the objective is wrong or the design is.
Test the awkward cases too. Can you restore when the primary site is unreachable and only the offsite copy exists? Can you decrypt data if the key management system is offline? Can you recover from a point in time before a destructive change, not just the most recent copy? Record what you learn, fix the gaps, and repeat. Restore testing is not a one-time project; it is the maintenance that keeps a backup strategy honest.
6 Offsite and encryption
Offsite storage is what turns a local backup into a disaster recovery capability. The copy should live in a different failure domain from the primary data, which may mean another building, another region, or another provider. Distance matters less than independence: two data centers on the same power grid or the same network segment may fail together. For smaller environments, encrypted removable drives rotated to a safe location can satisfy the offsite requirement, provided the rotation schedule is followed and the media are stored properly.
Encryption protects backups in two directions. At rest, it prevents anyone who obtains the media or storage account from reading the contents. In transit, it prevents interception while copies move between sites. Use strong, current algorithms and manage keys separately from the data they protect, because a backup encrypted with a lost key is indistinguishable from no backup at all. Store key material where it will survive the loss of the primary environment, and document who can retrieve it during an emergency.
Encryption also interacts with retention and deduplication. Some schemes weaken when keys are rotated frequently, and some deduplication systems leak information about identical blocks. Decide early whether keys are per-backup, per-device, or per-tenant, and test a restore using only the escrowed key. The combination of an offsite copy, strong encryption, and a verified key recovery path is what lets you treat the backup as a genuine last resort.
7 Frequently asked questions
Are snapshots useless, then? No. They are excellent for fast rollback of recent logical errors and for creating consistent staging points for backup jobs. The mistake is relying on them as the only copy. Use snapshots for convenience and backups for survival, and make sure the backup does not depend on the snapshot system being healthy.
How often should I test restores? Often enough that the process stays familiar and the results stay current. A practical baseline is a small file-level restore every week or month, a fuller application restore every quarter, and a complete disaster exercise at least annually or whenever the infrastructure changes significantly. Adjust to your recovery objectives and regulatory obligations.
Do I need immutability? It is strongly recommended when ransomware or insider risk is in scope, because it prevents deletion or alteration of backups during the retention window. Immutable or offline copies, combined with separate credentials, remove the easiest path an attacker has to destroy your recovery options.
How do I know my backups are good? Only by restoring them and checking the result. Track restore success, restore duration, and any errors, and treat a failed test as an incident with a fix and a retest. If you cannot demonstrate a successful restore, you do not yet have a backup you can count on.