1 Overview
Snapshots are often described as backups, but they are not the same thing. A snapshot is a point-in-time image of a storage volume or file system. It is fast, space-efficient, and useful for rolling back a change or recovering a file from an accidental deletion. However, a snapshot usually depends on the same underlying storage system, the same administrative domain, and often the same credentials as the production data. If that storage system is corrupted, encrypted by ransomware, or lost in a site failure, the snapshot may be lost or unusable along with the primary data.
A backup is an independent copy of data that can be used to restore after loss, corruption, or disaster. It is deliberately separated from the primary system in location, access path, and often in technology. The 3-2-1 rule captures this separation: keep at least three copies of data, on two different media types, with one copy offsite. Snapshots can be part of a broader data protection strategy, but they should not be the only copy. The real test of any backup is whether it can be restored, not whether it exists.
This article explains what snapshots do well, where they fall short, and how to build a recovery plan that actually works when you need it. It focuses on practical decisions about strategy, retention, restore testing, offsite storage, and encryption. The goal is not to sell a product but to help you avoid the common mistake of treating a snapshot as a complete backup.
2 What you are actually protecting against
Data loss comes from many directions, and each threat requires a different kind of protection. Accidental deletion, overwriting, or a bad application update can corrupt data logically. In those cases, a recent snapshot or backup can help, but only if the corruption is detected before the snapshot ages out. Ransomware is more aggressive: it may encrypt production data and then target connected snapshots and backup repositories. If the backup system uses the same credentials or network path as production, it can be compromised too. A truly independent copy, ideally immutable or offline, is the stronger defense.
Hardware failure and storage corruption are also common. A disk may fail, a RAID controller may lose its configuration, or a file system may become inconsistent. Snapshots on the same array may not survive that failure. Natural disasters, fires, floods, and power events can destroy an entire site. Human error, from a mistyped command to a misconfigured script, remains a leading cause of outages. Insider threats and malicious deletion add another layer. Each of these scenarios tests a different assumption: that the copy is recent, that it is isolated, that it is readable, and that it can be restored within the required time.
A useful exercise is to list the specific failure modes that matter to your organization and then ask which copy would survive each one. If the answer is always the same snapshot, you have a single point of failure. The purpose of a backup strategy is to ensure that no single event, whether accidental or deliberate, can destroy every usable copy of your data at once.
3 Choosing a backup strategy
A backup strategy starts with recovery objectives. The recovery point objective, or RPO, defines how much data you can afford to lose, measured in time. If your RPO is one hour, you need backups or replication that can restore data to within the last hour. The recovery time objective, or RTO, defines how long you can tolerate being down. A low RTO may require faster media, local staging, or automated recovery, while a higher RTO allows slower and cheaper methods. These objectives should come from the business, not from the backup tool.
Next, choose the backup types and schedule that meet those objectives. Full backups capture everything and simplify restores but take longer and use more space. Incremental backups capture changes since the last backup and are efficient, but restore chains can be longer. Differential backups capture changes since the last full backup and offer a middle ground. A common approach is a periodic full backup with regular incrementals, plus separate copies for long-term retention. The schedule should match how quickly data changes and how much loss is acceptable.
Finally, decide where copies live and how they are protected. Local backups on a separate system can speed restores, while offsite copies protect against site loss. Immutable or offline copies defend against ransomware and malicious deletion. Document the strategy, assign ownership, and review it as data volumes and threats change. A strategy that is not written down and tested is only a hope. The best strategy is the one your team can actually operate under pressure.
4 The 3-2-1 rule in practice
The 3-2-1 rule is a simple framework: at least three copies of data, on two different media types, with one copy offsite. In practice, the three copies might be the production data, a local backup on a separate storage system, and an offsite copy in a cloud region or remote data center. The two media types could be disk and tape, or disk and cloud object storage, or two independent disk systems from different vendors. The offsite copy must be far enough away that a local disaster cannot affect both the primary and the offsite copy.
Applying the rule requires attention to independence. If all three copies are reachable with the same administrator credentials, a single compromised account can delete or encrypt them. If the offsite copy is in the same cloud account as production, a misconfiguration or account compromise can affect both. Stronger implementations use separate accounts, separate credentials, immutable storage, and network isolation. Some organizations add a fourth copy that is offline or air-gapped, especially for critical data. The rule is a minimum, not a maximum.
It also helps to label each copy with its purpose. The production copy serves live operations. The local backup enables fast restores for common issues. The offsite copy protects against site loss and major disasters. The offline copy defends against ransomware and insider threats. When you can explain what each copy protects against, you can test it appropriately. The 3-2-1 rule is not about counting copies for its own sake; it is about ensuring that no single failure can take them all out.
5 Restore is the real test
A backup that has never been restored is an assumption, not a guarantee. Restore testing is the only way to know whether your data is readable, your procedures work, and your team can meet the RTO. Testing should cover different scenarios: restoring a single file, restoring an entire server, restoring an application database, and recovering from a full site loss. Each scenario exercises different parts of the backup system, from the backup catalog to the network to the application configuration. Start with small, frequent tests and schedule larger tests at least quarterly or annually, depending on criticality.
During a test, measure the actual restore time and compare it to the RTO. Verify that the restored data is complete and consistent, not just present. Check permissions, ownership, and application dependencies. A database may restore but fail to start because a configuration file or transaction log is missing. An application may need a specific order of restoration. Document the steps, the time taken, and any issues found. Treat every test as a rehearsal for a real incident, and fix problems before they matter.
Stress testing restores also means testing under adverse conditions. What happens if the primary site is down and the team is working remotely? What if the backup network is congested? What if the person who knows the procedure is unavailable? Run a test that simulates a real disaster, including communication and decision-making. After each test, update the runbook and retrain the team. The goal is not a perfect test score but a reliable recovery capability. If you cannot restore within your RTO, you need to change the strategy, not just the documentation.
6 Offsite and encryption
Offsite storage is a core part of the 3-2-1 rule because it protects against events that destroy an entire location. The offsite copy should be in a different geographic region, with separate power, network, and administrative controls. Cloud object storage is a common choice because it is durable and scalable, but it must be configured correctly. Use a separate account or subscription from production, restrict access with least privilege, and enable immutability or object lock where available. If the offsite copy is reachable from production with the same credentials, it is not truly isolated.
Encryption is essential for offsite copies, especially when data leaves your premises or crosses a network. Encrypt data in transit and at rest. Manage keys separately from the backup data, because if the keys are stored with the backups, an attacker who gains access to the backup repository may also gain access to the keys. Consider using a key management service or hardware security module, and define a key rotation and recovery process. Losing encryption keys can make your backups permanently unreadable, so key backup and escrow must be part of the plan.
Encryption also affects restore testing. You must verify that you can decrypt and restore data using the documented key recovery process. Test with the same keys and procedures you would use in a disaster. Remember that encryption protects confidentiality, but it does not replace independence or immutability. A well-designed offsite copy is encrypted, access-controlled, immutable where possible, and tested regularly. Together, these controls make the offsite copy a reliable last line of defense.
7 Frequently asked questions
Is a snapshot a backup? No. A snapshot is a point-in-time image that usually depends on the same storage system and administrative domain as the primary data. It can be useful for quick rollbacks, but it is not an independent copy. A backup should be separate in location, access path, and ideally media type, so it can survive the failure or compromise of the primary system.
How often should I test restores? Test small restores frequently, such as monthly, and perform larger recovery tests at least quarterly or annually. The frequency should match the criticality of the data and the complexity of the environment. Every test should measure restore time against your RTO and verify data integrity. If a test fails, fix the issue and retest.
Do I need encryption for backups? Yes, especially for offsite copies. Encrypt data in transit and at rest, and manage keys separately from the backup data. Test key recovery as part of your restore testing. Encryption protects confidentiality, but it does not replace the need for independent, immutable copies.
How many copies do I really need? The 3-2-1 rule is a minimum: three copies, two media types, one offsite. High-risk environments may need additional offline or air-gapped copies. The right number depends on your threats, RPO, RTO, and budget. More important than the count is the independence of each copy and your ability to restore from it.
What is the biggest mistake? Treating snapshots as backups and never testing restores. A backup strategy is only as good as its last successful restore. Document your plan, assign ownership, and rehearse recovery regularly.