1 Overview
Backup software reports success, but success is not the same as recoverability. A job can finish with green checkmarks while the backup set is incomplete, the encryption key is missing, or the restore path has never been exercised. The only meaningful measures of a backup program are recovery point objective, the maximum acceptable data loss measured in time, and recovery time objective, the maximum acceptable downtime before service is restored. Those two numbers define what the business can tolerate, and everything else in the backup design should serve them.
RPO and RTO are business decisions, not technical preferences. A finance system may tolerate minutes of lost transactions, while a document archive may tolerate a day. Once those targets are agreed, they determine backup frequency, retention, replication, and the class of storage used. A backup that cannot meet the stated RPO or RTO is not a backup; it is a hope. This article explains how to test whether your software is telling the truth, how to design around RPO and RTO, and why restore testing and encryption are non-negotiable parts of the program.
2 What you are actually protecting against
Backups protect against more than disk failure. Ransomware encrypts primary data and often targets connected backups, so an isolated or immutable copy is essential. Accidental deletion and overwrites remain among the most common causes of data loss, and they are usually discovered long after the fact. Application bugs, failed upgrades, and corrupted databases can silently damage records that look fine until a restore is attempted. Hardware faults, power events, and storage controller failures still occur, even in cloud environments.
Site-level events such as fire, flood, theft, or a regional outage require an offsite copy that is not dependent on the same building, network, or credentials. Insider action, whether malicious or careless, can delete or alter data with legitimate access. Legal and regulatory obligations may require retention of specific records for years, independent of operational recovery. Each threat implies different requirements: ransomware demands immutability and offline isolation, while site loss demands geographic separation. A credible program maps each threat to a control and then verifies the control works.
The uncomfortable truth is that many organizations discover their gaps only during an incident. A backup that shares credentials with the production domain, or that lives on the same storage array, will not survive the exact events it was meant to address. Threat modeling should precede tool selection, not follow it.
3 Choosing a backup strategy
Start with the RPO. If the business can lose at most one hour of data, then backups or continuous replication must run at least hourly, and the recovery chain must not depend on a daily full that takes longer than the window. RTO then shapes the restore method: restoring from tape or cold cloud storage may take days, while snapshots and replicated volumes can restore in minutes. The strategy must fit both numbers simultaneously, because a fast backup with a slow restore still fails the RTO.
A practical approach combines full backups at a cadence that bounds restore complexity with incremental or differential backups in between. Full backups simplify recovery but consume storage and bandwidth; incrementals reduce load but lengthen the chain and increase the chance that one missing piece breaks the restore. Synthetic fulls and changed-block tracking can reduce the burden, but they must be validated. Retention should be tiered so recent recovery points are fast to access and older ones are cheap to store, with at least one copy protected from deletion.
Document the dependency order for multi-tier applications, including databases, application servers, and identity services. A restore that brings up the web tier before the database is ready will fail even if every file is intact. Finally, define who can authorize a restore, who performs it, and how the decision is communicated, because recovery is an operational process, not only a storage operation.
4 The 3-2-1 rule in practice
The 3-2-1 rule states that you keep at least three copies of data, on two different media types, with one copy offsite. In practice, that means the production data plus two backups, stored so that a single failure cannot destroy all copies. Two media types might be local disk for fast restores and object storage or tape for durable retention. The offsite copy must be genuinely separate: different region, different account, different credentials, and ideally different administrative control.
Modern variants extend the rule to 3-2-1-1-0, adding one immutable or offline copy and zero errors verified by testing. Immutability prevents ransomware or a compromised administrator from deleting or encrypting the backup during the retention window. Offline copies, such as rotated drives or air-gapped tape, provide the strongest isolation but require physical handling and tracking. Cloud object storage with object lock can provide immutability without physical media, provided the retention settings and legal holds are configured correctly.
The rule is a floor, not a ceiling. It does not specify frequency, retention, or restore speed, so it must be paired with RPO and RTO targets. It also does not guarantee that the copies are usable. A three-copy strategy with untested restores can still fail. Treat 3-2-1 as the structural minimum and let the recovery objectives determine how often each copy is refreshed and how quickly it can be brought back into service.
5 Restore is the real test
A backup job that reports success proves only that data was written somewhere. The real test is a restore, performed on a schedule, into an environment that resembles production. Start with file-level restores to confirm basic integrity, then move to application-level restores that include databases and configuration. Finally, perform a full recovery exercise that rebuilds a service from backups alone, without relying on the surviving production systems. Record how long each step takes and compare it with the RTO.
Test restores should be routine, not exceptional. Monthly file restores, quarterly application restores, and annual full failover exercises give a realistic picture of readiness. Include the people who would actually perform recovery, not only the backup administrators, and test the communication and authorization path as well. Verify that encryption keys and credentials are available to the people who need them, and that they are stored separately from the backups they protect. A restore that cannot be decrypted is a failed restore.
Track restore success rates, elapsed times, and any manual steps that were required. Each manual step is a risk during a real incident, when stress and time pressure are high. Automate where possible, document what remains manual, and fix the gaps found in testing. The goal is not a perfect test; it is a truthful measurement of how much data you would lose and how long you would be down.
6 Offsite and encryption
Offsite protection guards against events that destroy or isolate the primary site. The offsite copy should be encrypted in transit and at rest, and the keys should be managed so that a compromise of the backup storage does not expose the data. Encryption also protects portable media, which can be lost or stolen. Use strong, current algorithms and avoid deprecated ciphers, and rotate keys according to policy while ensuring that older backups remain decryptable.
Key management deserves as much attention as the backup itself. Store keys separately from the encrypted data, restrict access to a small set of administrators, and document recovery procedures in case the primary key custodian is unavailable. Test decryption as part of restore exercises. If the key is lost, the backup is effectively gone, regardless of how many copies exist. Consider hardware security modules or managed key services where the risk justifies the cost.
Offsite replication must also respect the RPO. If replication runs once a day, the offsite copy can be up to a day behind, which may exceed the target. Bandwidth, change rates, and storage costs determine what is feasible. Finally, verify that the offsite environment is isolated from production credentials and networks, so that a compromise of the primary environment cannot cascade into the backup copies.
7 Frequently asked questions
How often should backups run? The answer follows from the RPO. If losing an hour of data is unacceptable, run at least hourly. If losing a day is acceptable, daily may suffice. Frequency also depends on change rate and the cost of running backups during business hours. More frequent backups reduce potential loss but increase storage, bandwidth, and management overhead, so align frequency with a documented business decision rather than a default setting.
How long should backups be kept? Retention is driven by legal, regulatory, and operational needs. A common tiered approach keeps daily copies for weeks, weekly copies for months, and monthly or annual copies for years. Longer retention increases cost and the number of copies that must be protected and tested. Keep at least one copy immutable or offline for the full retention period, and document why each tier exists.
What is the difference between RPO and RTO? RPO defines how much data you can afford to lose, measured in time before the incident. RTO defines how long you can afford to be down while recovering. Both must be agreed by the business and tested. Can cloud backups replace offsite tape? Often yes, if immutability, isolation, and encryption are configured correctly, but the choice depends on cost, recovery speed, and compliance. How do we know backups work? Only by restoring them regularly and measuring the results against the RPO and RTO.