1 Overview
Snapshots are convenient, fast, and easy to schedule, which is exactly why so many teams quietly let them become the only copy of important data. A snapshot is a point-in-time reference to blocks or files on the same storage system that holds the live data. It is a rollback mechanism, not an independent backup. If the underlying array, volume group, or storage account is lost, the snapshot usually goes with it.
This article explains how to separate snapshots from backups and how to set recovery point objectives and recovery time objectives that match real business needs. The recovery point objective, or RPO, is how much data you can afford to lose, expressed as time. The recovery time objective, or RTO, is how long you can afford to be without the data or service. Both are decisions about acceptable loss, not technical settings, and they should drive the backup design rather than the other way around.
Once RPO and RTO are explicit, the rest of the design follows: how often to copy, where copies live, how long to keep them, and how often to prove they can be restored. The goal is a recovery capability you can demonstrate, not a dashboard that merely reports successful jobs.
2 What you are actually protecting against
Backups exist to survive failure modes that snapshots cannot. The first is storage loss: a failed array, a deleted volume, a corrupted file system, or a storage account that is accidentally removed. Snapshots on that same system are destroyed or invalidated along with the primary copy, so they provide no protection at all in this scenario.
The second is logical corruption and human error. A bad script, a faulty application upgrade, or a mistaken bulk delete can damage data and then propagate into snapshots taken afterward. If the snapshot chain is the only recovery source, the useful point in time may already be overwritten by the time anyone notices. Ransomware behaves similarly: it encrypts live data and often targets snapshot and backup repositories specifically, which is why at least one copy must be isolated and immutable.
The third is site-level or regional failure. Fire, flood, power loss, network isolation, or a provider outage can take out an entire location. Any copy that lives only in that location is unavailable exactly when it is needed. Finally, there is silent data loss: bit rot, failed writes, and undetected corruption that only surface when you try to read the data. Independent copies with integrity checking are what catch these cases, and snapshots alone rarely do.
3 Choosing a backup strategy
Start from RPO and RTO, then choose copy frequency and media to meet them. A short RPO, meaning little tolerance for lost data, requires frequent copies, which usually means frequent snapshots plus regular incremental backups to independent storage. A long RTO, meaning the business can wait, allows slower and cheaper media. A short RTO forces you to think about restore speed, not just copy frequency, because a fast backup that takes days to restore does not meet a tight RTO.
A practical pattern is tiered. Keep frequent local snapshots for quick rollback of small mistakes, and write scheduled full and incremental backups to separate storage that does not share fate with the primary system. Retain daily copies for a few weeks, weekly copies for a few months, and monthly or quarterly copies for as long as compliance or operational need requires. Longer retention protects against slow-burning corruption and late-discovered problems.
Match the method to the data. Databases often need application-consistent backups or transaction log shipping to hit a tight RPO. File shares and object stores can use incremental or change-block tracking. Virtual machines can use image-level backups with agent-based options where needed. Whatever the mix, document which data set maps to which RPO and RTO, and review that mapping when systems or business requirements change.
4 The 3-2-1 rule in practice
The 3-2-1 rule says keep at least three copies of data, on two different media or storage types, with one copy offsite. In practice, the three copies are the live data, a local backup copy, and an offsite copy. Snapshots can count as a convenience layer, but they should not be counted as one of the three independent copies when they live on the same system as the primary data.
The two media requirement is about avoiding a single point of failure in the storage technology itself. A local disk-based backup target plus an object store, tape, or a second storage platform gives you diversity. If a firmware bug, controller failure, or provider-side issue affects one platform, the other remains readable. The offsite copy protects against site loss and gives you a recovery path when the primary location is unavailable.
Implementing 3-2-1 also means separating credentials and access. The offsite copy should not be deletable by the same account or role that can delete production data, or a single compromised credential can erase everything. Immutability or object lock, where available, adds a retention window that even an administrator cannot shorten. Verify that each copy is complete and readable, and keep the copy count honest: three copies that all depend on one storage system are really one copy.
5 Restore is the real test
A backup job that reports success proves only that data was written somewhere. It does not prove the data can be read, mounted, or used to bring a service back. The only meaningful measure is a restore, and restores should be tested on a schedule rather than assumed. A common approach is to restore a sample of files, a database, and a full system image into an isolated environment, then confirm the recovered data is complete and the application starts.
Stress testing means going beyond a single file. Restore an entire virtual machine, recover a database to a specific point in time, and measure how long each step actually takes. Compare that measured time against your RTO. If a full restore takes longer than the business can tolerate, the design needs to change: faster media, more parallel streams, a warm standby, or a smaller recovery scope. Testing also reveals dependencies that backups do not capture, such as configuration, certificates, DNS records, and application credentials.
Document the restore procedure and the measured times, then repeat the test periodically and after major changes. Track failures and fix them before a real incident. Encryption matters here too: encrypted backups are only useful if the keys are available and tested during recovery. Store keys separately from the backup data, restrict access, and include key recovery in the test plan so a restore never fails because the key was lost.
6 Offsite and encryption
Offsite means a separate failure domain, not merely a different room in the same building. A second data center, a colocation facility, or an isolated cloud or object store region all qualify if they do not share power, network, or administrative fate with the primary site. The offsite copy should be written regularly enough to meet your RPO and verified often enough that you trust it. Network bandwidth, transfer windows, and egress costs shape how often that copy can be refreshed.
Encryption protects data in transit and at rest, and it is essential for offsite copies that leave your physical control. Encrypt backups before they leave the source where possible, so the storage provider or transport path never sees plaintext. Use strong, current algorithms and manage keys deliberately: separate key custody from backup custody, rotate keys on a schedule, and keep an offline or escrowed copy of the keys so recovery is possible if the primary key store is lost.
Encryption introduces a hard dependency. A lost or corrupted key turns a perfect backup into unreadable noise, so key availability is part of your RTO. Test decryption during restore exercises, confirm that restored data is usable, and restrict who can access both the backups and the keys. Combine encryption with immutability and least-privilege access so that even a compromised account cannot quietly delete or overwrite the copies you will need.
7 Frequently asked questions
Are snapshots ever enough? Snapshots are enough for fast rollback of a recent mistake when the primary storage is healthy. They are not enough as a sole recovery method, because they share fate with the primary data and are often overwritten quickly. Treat them as a convenience layer on top of independent backups.
How often should backups run? Frequency follows RPO. If you can tolerate losing one hour of data, copy at least hourly. If you can tolerate a day, daily copies may suffice. Snapshots can run more often than backups, but the backup schedule is what defines your true recovery point.
How long should copies be kept? Retention follows both recovery needs and any compliance obligations. Keep enough history to recover from slow corruption and late-discovered errors, and keep at least one copy long enough that a problem unnoticed for weeks is still recoverable. Longer retention costs more, so tier it deliberately.
Do I need offsite copies if I use cloud storage? Yes, if the primary data and the cloud copy share the same account, region, or credentials. Use a separate failure domain, separate credentials, and immutability where possible. Finally, test restores and key recovery regularly, because an untested backup is only a hope.