1 Overview
A backup is a copy. Data recovery is the process of turning that copy back into usable data, applications, and services. The gap between the two is where most organizations get surprised. A backup job that reports success only proves that data was written somewhere. It does not prove that the data can be read, that the application can start, that dependencies are present, or that the restore will finish inside the time the business can tolerate.
This article treats backup as one part of a larger recovery capability. The goal is not to collect the most copies or the most impressive tooling. The goal is to be able to answer a simple question with evidence: if the primary system disappeared right now, how long would it take to bring it back, and how much recent data would be missing? Those two numbers, recovery time and recovery point, are the measures that matter. Everything else, including the backup schedule and the storage layout, exists to make those numbers true.
Testing is what converts a backup plan into a recovery plan. A restore that has been performed, timed, and verified is worth more than a dozen backup jobs that have never been read back. The rest of this article explains what to protect against, how to choose a strategy, how the classic 3-2-1 rule fits, why restore testing is the real exam, and how offsite storage and encryption fit together.
2 What you are actually protecting against
Data loss is not a single event. It arrives through several distinct paths, and each path demands a different recovery response. Hardware failure removes a disk, a controller, or an entire server. Human error deletes the wrong file, drops the wrong table, or overwrites the wrong record. Software defects and failed upgrades corrupt data silently, sometimes for days before anyone notices. Ransomware encrypts production data and then hunts for the backups. Theft and physical damage remove equipment entirely. Fire, flood, and power events can take out a whole room.
These threats differ in speed, scope, and stealth. A failed disk is loud and immediate. A bad migration may be quiet and partial. Ransomware may sit dormant while it maps the environment and destroys recovery points. That is why a single backup method is rarely enough. A snapshot protects against a mistaken file deletion but not against a fire in the same building. An offsite copy protects against site loss but may be too old to meet a tight recovery point. A versioned archive protects against slow corruption but is slow to restore.
The right question is not which threat is most likely. It is which combination of copies, locations, and retention periods covers the realistic failure modes for this system. Map each threat to at least one copy that survives it, and confirm that the copy can actually be restored. If a threat has no surviving copy, the plan has a hole regardless of how many backup jobs run each night.
3 Choosing a backup strategy
Start with the data itself. Identify what must be recovered, how much change occurs between backups, and how quickly the business needs it back. That analysis produces two targets: a recovery point objective, which is the maximum acceptable amount of lost data, and a recovery time objective, which is the maximum acceptable downtime. These targets drive every later decision, including backup frequency, storage type, and whether replication or standby systems are needed.
With targets set, choose the copy types. Full backups capture everything and simplify restores but consume time and space. Incremental backups capture only changes since the last backup and are fast and small, but a restore may need the full plus every increment in the chain. Differential backups capture changes since the last full and sit between the two in cost and complexity. Many environments combine a periodic full with frequent incrementals, then add image or snapshot captures for fast system-level recovery. Versioning matters as much as frequency, because overwriting the only good copy with a corrupted one turns a recoverable incident into a permanent loss.
Match the method to the recovery target. If the recovery point must be minutes, backups alone may not be enough and replication or continuous capture may be required. If the recovery time must be short, prefer restore paths that are simple and well rehearsed over clever chains that save storage but add steps. Document the strategy, including what is backed up, how often, where copies live, and who can restore them. A strategy that exists only in one person's head is a single point of failure.
4 The 3-2-1 rule in practice
The 3-2-1 rule is a simple discipline: keep at least three copies of important data, on at least two different types of storage media, with at least one copy stored offsite. The first copy is production data. The second and third are backups. The two media requirement reduces the chance that one failure mode, such as a controller bug or a bad batch of drives, destroys every copy at once. The offsite requirement ensures that a local disaster does not take the backups with it.
In practice, a common layout is production storage, a local backup target on different media, and an offsite or cloud copy. The local copy supports fast restores for routine incidents such as deleted files or failed upgrades. The offsite copy supports recovery from site loss, theft, or ransomware that reaches the local network. Some teams extend the rule to 3-2-1-1-0, adding one copy that is offline or immutable and a verification step that confirms zero errors in the restore. The extra digits are not magic. They simply force attention onto two weaknesses that 3-2-1 alone does not address: backups that are reachable by an attacker and backups that have never been tested.
The rule is a floor, not a ceiling. It says nothing about frequency, retention, or restore speed, so it must be combined with the recovery targets from the previous section. It also says nothing about encryption or access control, which determine whether a stolen copy becomes a breach. Use 3-2-1 as the minimum topology, then layer scheduling, retention, testing, and security on top until the plan meets the actual recovery objectives.
5 Restore is the real test
A backup that has never been restored is a hypothesis. Restore testing turns it into evidence. The test should answer concrete questions: can the data be read, can the application start, are the dependencies present, how long did it take, and how much data was missing compared with the recovery point target. A successful backup log answers none of these. Only a restore does.
Design tests at several levels. Start with a file-level restore to confirm that individual items can be recovered quickly. Move to an application-level restore to confirm that databases, configuration, and services come back in a working state. Then run a full system or site-level exercise to measure the end-to-end recovery time against the objective. Test the awkward cases too: a restore from the oldest retained copy, a restore when the primary site is unavailable, a restore performed by someone other than the person who built the system. These scenarios expose gaps that a routine test hides.
Record the results and treat failures as findings, not embarrassments. A restore that takes twice as long as expected, or that reveals a missing encryption key or an expired credential, is a problem discovered at the best possible time. Schedule tests on a regular cadence, rotate the people who perform them, and keep the runbooks current. Stress testing restores, including partial failures and degraded conditions, is how an organization learns whether its recovery plan works before a real incident forces the question.
6 Offsite and encryption
Offsite storage protects against events that destroy or deny access to the primary location: fire, flood, theft, power loss, and ransomware that spreads across the local network. The offsite copy should be isolated from the production environment so that a compromise of production does not automatically reach it. Options include a secondary data center, a cloud region, or removable media stored in a separate facility. The key property is separation, not distance for its own sake.
Encryption protects the copies themselves. Encrypt data at rest on backup media and in transit between sites, and manage keys separately from the backups. A stolen encrypted backup is a contained incident; a stolen unencrypted backup is a data breach. Key management deserves the same care as the data, because a lost key makes every copy useless. Store keys where they can be retrieved during a disaster, and test that retrieval as part of restore exercises. Access controls, audit logs, and immutable or offline copies further reduce the chance that an attacker can delete or alter recovery points.
Offsite and encryption interact with recovery time. Retrieving data from a remote location or decrypting a large archive adds minutes or hours to a restore, so factor those steps into the recovery time objective. Verify that the offsite copy is complete and readable, not merely present. A remote copy that cannot be decrypted or restored is no better than no copy at all, and it may create false confidence that delays a proper response.
7 Frequently asked questions
How often should backups run? Frequency follows the recovery point objective. If losing a day of data is acceptable, daily backups may suffice. If losing an hour is not, backups or replication must run more often. The schedule is a business decision expressed in technical terms, not a default setting.
How many copies are enough? The 3-2-1 rule is a reasonable minimum: three copies, two media types, one offsite. Add an offline or immutable copy and a verified restore if ransomware or insider threats are in scope. More copies do not help if none of them can be restored.
How long should copies be kept? Retention depends on regulation, business value, and how far back corruption or theft might have occurred. A common pattern is frequent short-term copies plus less frequent long-term copies. Keep at least one copy old enough to predate a slow, undetected problem.
What is the difference between backup and disaster recovery? Backup is the practice of making and storing copies. Disaster recovery is the broader capability of restoring services, including people, procedures, infrastructure, and testing. Backup is necessary but not sufficient for recovery.
Do we need to test restores? Yes. Untested backups are unproven. Test file, application, and full-system restores on a schedule, measure the results against recovery targets, and fix what fails. Stress testing restores under degraded conditions is the most reliable way to know the plan will work when it matters.