Backup Design and Recovery
Before you start
Who is this for?
For IT administrators and service owners who need dependable recovery plans.
Prerequisites
- Basic storage and system administration concepts
What you'll be able to do
- Compare backup methods
- Set RPO and RTO
- Protect copies
- Plan and verify a restore
Practical outcome
Document a practical restore test and compare it with recovery objectives.
A backup is a recoverable copy kept so data or a service can be restored after loss or corruption. Redundancy keeps another component available during some failures; it may replicate accidental deletion, corruption, or ransomware just as quickly. RAID, replicas, and synchronized folders are not substitutes for independent backups.
Learning objectives
Section titled “Learning objectives”- Compare full, incremental, and differential backups.
- Set recovery point and recovery time objectives.
- Protect copies from common failure modes and verify a restore.
Backup methods and the 3-2-1 heuristic
Section titled “Backup methods and the 3-2-1 heuristic”A full backup copies the selected data set. An incremental backup copies changes since the previous backup of any type; restore may require the full plus each required incremental. A differential backup copies changes since the last full; restore typically needs the full plus the latest differential. Products use these terms with implementation-specific details, so check the product’s restore chain behavior.
The common 3-2-1 heuristic recommends three copies of important data, on two types of storage, with one copy off-site. It is a planning heuristic, not a guarantee or a formal compliance standard. Add an offline or immutable copy where practical so compromised credentials cannot readily alter every copy. CISA recommends offline, encrypted backups and regular restoration tests in its ransomware guidance.
Set recovery targets
Section titled “Set recovery targets”- Recovery Point Objective (RPO): the maximum acceptable amount of data loss measured in time. If RPO is four hours, backup/replication design must support restoring to a point no more than four hours before the incident, subject to the actual data and failure mode.
- Recovery Time Objective (RTO): the target time to restore a service to an agreed usable state.
These targets are business decisions. A database, identity service, and archival file share may need different targets. Include dependencies, staff, access to keys, and network capacity in recovery planning. NIST’s contingency planning guide discusses recovery planning for information systems.
Protect copies and retention
Section titled “Protect copies and retention”Encrypt backup data in transit and at rest when appropriate, and protect encryption keys separately with tested recovery procedures. Restrict administration, use separate credentials or accounts, monitor deletion/configuration changes, and retain copies long enough to recover from delayed discovery. Retention must reflect legal, operational, and privacy requirements; keep only what is needed and authorized.
A backup is only useful if it can be read and restored. Test representative files and complete service recovery in an isolated or controlled environment. Verify data integrity, permissions, application consistency, and that the service starts. Record duration against RTO, restore point against RPO, prerequisites, problems, and corrective actions.
Common failure modes
Section titled “Common failure modes”- Backups silently fail or omit new systems and data.
- The same administrator credentials can delete production and every backup.
- Replication copies corruption or deletion before anyone notices.
- Retention is too short to reach a clean restore point.
- Backup metadata, encryption keys, or restore instructions are unavailable during an outage.
- A successful job is mistaken for a successful restore.
Practical restore check
Section titled “Practical restore check”- Select a non-production test file or service with an owner-approved recovery objective.
- Restore to an isolated location without overwriting production.
- Verify checksums or application-level integrity, permissions, and expected contents.
- Measure elapsed time and identify the recovery point.
- Record the result and update runbooks, access paths, and retention where needed.
For a suspected ransomware incident, coordinate recovery with incident responders. Avoid reconnecting restored systems to an untrusted environment before containment and validation.
Document a practical restore test and compare it with recovery objectives.
Related: Security Fundamentals, Vulnerability Management.