Backup

What a backup is

A backup is a recoverable copy of files, applications, configurations, or other system state created for restoration after accidental deletion, corruption, hardware failure, disaster, or attack. The required scope depends on what the organization must recover: copying a database is not enough if the application configuration and other dependencies needed to use it are missing.

Design from recovery objectives

Start with business criticality, the Recovery Point Objective (RPO), and the Recovery Time Objective (RTO). The backup frequency and available restore points must support the acceptable data-loss window, while the restoration process, people, and infrastructure must support the target recovery time. Define scope, schedule, retention, owners, access controls, protection of sensitive copies, and monitoring of failed jobs.

The 3-2-1 rule is a useful baseline: keep three copies in total, use two different media types, and store one copy off-site. For ransomware resilience, keep at least one current copy offline or otherwise isolated from production access so that compromised credentials cannot reach every restore point.

Prove that restoration works

A successful backup job proves that data was copied, not that a service can be recovered. Test representative file and full-service restores, verify integrity and required configurations, and record whether recovery objectives were met. Findings from exercises should update the procedure, capacity, and backup scope.

Backup, replication, and archiving

Replication and high availability keep another system ready, but can quickly reproduce deletion or corruption. An archive preserves information for long-term reference or retention. Neither automatically provides versioned, independently accessible restore points, so neither is a substitute for a tested backup.