Backup Fundamentals

A backup is a recovery copy. Its value appears only when you can use it to recover files, systems, or services after loss or damage.

That definition makes backup a recovery capability, not a storage purchase. A successful job creates a copy. A successful backup program can find the right copy, protect it, restore it, and prove the restored result works.

Use this mental model:

business need
    -> recovery objectives
    -> protected copies
    -> monitored backup jobs
    -> tested restore
    -> usable service

Every arrow can fail. A green backup job does not prove that the final service is usable.

Why backups exist

Production data can disappear or become unusable through accidental deletion, corruption, hardware failure, software defects, malicious action, or a site-wide event. Backups preserve recovery points outside the live state.

The recovery point matters because the newest state may already be damaged. If ransomware encrypted files at noon, a copy made at one o'clock may preserve the encryption. You need enough retained versions to reach a known-good point before the damage.

Backups also support different recovery scopes. You may need one file, one database, an entire server, or a coordinated set of applications. The required scope changes what you copy and how you test it.

Start with recovery objectives

Do not start with a product or schedule. Start with the business impact of losing data and time.

The recovery point objective, or RPO, defines the point in time to which data must be recovered after an outage. It expresses tolerable data loss as time. If the RPO is four hours, the recovery design must make a usable recovery point at least every four hours.

The recovery time objective, or RTO, defines how long recovery can continue before the outage harms the mission or business process. It includes more than copying bytes. Detection, authorization, infrastructure preparation, restore work, validation, and service return all consume that time.

RPO and RTO are targets, not measured results. A restore exercise tells you whether the implementation can meet them.

Retention answers a different question: how far back must recovery points remain available? A short RPO requires frequent copies. Long retention requires old copies to remain discoverable and usable. Neither requirement implies the other.

Define objectives per workload. A transaction database, source repository, workstation, and public web cache rarely need the same schedule or restore time.

Decide what recovery needs

A backup scope can include more than user files:

application data and databases
operating-system and application configuration
system state and virtual machine images
infrastructure definitions and deployment artifacts
documentation, recovery procedures, and dependency records
keys, certificates, licenses, and credentials needed during recovery

Do not copy secrets without also designing their protection and recovery. Encryption is useless if the recovery key disappears with the failed environment. A stored key is dangerous if every backup operator can read it.

Map dependencies before choosing scope. Restoring a database without its schema version, application configuration, identity service, or encryption key may produce complete bytes but no usable service.

Consistency also matters. A copy taken while related data changes can capture incompatible states. Use the workload's supported backup or snapshot mechanism when consistency requirements demand it. Confirm the result through restoration, not assumption.

Choose a backup method

Three common methods trade backup work against restore work.

Method	What it copies	Backup behavior	Restore chain
Full	All selected data	Highest recurring time and capacity	The selected full backup
Incremental	Changes since the previous backup	Smallest routine change set	A full backup plus every required incremental backup
Differential	Changes since the previous full backup	Grows until the next full backup	A full backup plus the selected differential backup

A full backup gives the shortest dependency chain. Incremental backups reduce routine transfer and storage, but recovery depends on more backup sets. Differential backups sit between those two patterns.

These labels describe relationships between recovery sets. Products can implement them differently through changed-block tracking, synthetic full backups, deduplication, or snapshots. Judge the design by recoverability, not by the label alone.

Backup frequency should follow the recovery point objective, data change rate, criticality, available backup window, and restore design. A convenient nightly schedule is not evidence that the business requirement is met.

Separate backup from adjacent mechanisms

Several technologies help availability or recovery but do not automatically provide an independent backup.

Replication copies changes to another system. It can reduce data loss and support availability for rapidly changing data. It can also copy an unwanted change. Retained recovery points remain necessary when you must return to an earlier state.

Redundancy and failover keep a service running through some component failures. They do not create historical recovery points. RAID, clustering, and a standby system can complement backups without replacing them.

Snapshots capture a point-in-time state. A snapshot contributes to backup only when its storage, retention, permissions, and recovery path survive the failures in scope. A snapshot controlled by the same compromised account may share the same fate as production.

File synchronization propagates current files between locations. It improves access to current state. It may also propagate deletion or corruption, so version history and isolation determine whether it can support recovery.

Archiving preserves information for long-term retention or records needs. Backup focuses on restoring operational state after loss. One system may serve both purposes, but the objectives and tests differ.

Build independent copies

The 3-2-1 rule is a useful starting heuristic:

Keep three copies, including production.
Use two different media types or storage systems.
Keep one copy offsite.

The rule reduces common-mode failure, but the numbers do not prove independence. Two storage systems under one administrator account may still share a credential failure. An offsite copy that remains online and writable may still be reachable by ransomware.

Define failure domains explicitly. Consider site loss, provider or region failure, account compromise, operator error, software defects, and ransomware. Place at least one recovery path outside the failure domain you need it to survive.

CISA recommends offline, encrypted backups for critical data and regular testing of backup availability and integrity. Offline can mean physically disconnected or logically inaccessible from the production path. Immutability can prevent alteration or deletion during a defined retention period. Each control addresses a different risk.

Protect the backup system

Backup data often contains the same sensitive information as production, plus broad historical coverage. Protect its confidentiality, integrity, and availability accordingly.

Restrict backup administration and restore authority.
Separate production and backup credentials.
Protect management interfaces and patch backup infrastructure.
Encrypt data in transit and at rest when the risk requires it.
Store recovery keys outside the failure domain of encrypted backups.
Monitor job failures, missed assets, capacity, retention, and deletion events.
Protect catalogs and configuration needed to locate and interpret recovery points.
Use offline, immutable, or separately administered copies where the threat model requires them.

Do not make recovery impossible through excessive separation. Authorized responders still need documented access during an outage. Test emergency credentials and approval paths.

Test restoration, not just backup creation

A backup report can confirm that software wrote data. It cannot confirm the entire recovery path.

A restore test should answer concrete questions:

Can you locate the required recovery point?
Can authorized staff retrieve it during a real outage?
Can the tool read the media and decrypt the data?
Is the restored data complete and internally consistent?
Are dependent systems, configurations, and keys available?
Does the application start and pass functional checks?
How much data was lost, and how long did recovery take?
What failed in the procedure, and who owns the correction?

Test at several scopes. Frequent sample restores catch routine media, permission, and catalog failures. Application restores test consistency and dependencies. Recovery exercises test people, procedures, infrastructure, and service order.

Record actual recovery point and recovery time results. Compare them with the objectives. Correct the design when the measurements miss the targets.

Operate backup as a lifecycle

A dependable program repeats a visible cycle:

Inventory workloads and owners.
Classify criticality and recovery scope.
Set RPO, RTO, and retention requirements.
Choose methods, locations, and protection controls.
Automate jobs and monitor coverage.
Test restores and measure outcomes.
Correct gaps after tests, incidents, and system changes.

Ownership matters throughout the cycle. A workload owner validates business data and application behavior. A platform or backup team operates the service. Security protects access and investigates suspicious changes. Recovery leadership decides service priority during a broad incident.

Review backup coverage whenever a workload, dependency, data classification, platform, or recovery objective changes. An unchanged job can become incomplete while still reporting success.

Limits and decision points

Backups reduce the impact of data loss. They do not prevent every outage, keep a service continuously available, or stop stolen data from being disclosed. They also do not identify a clean recovery point by themselves.

Use redundancy or replication when service continuity or very low data loss demands it. Keep backups when you need historical, protected recovery points. Use both when the business impact requires both availability and rollback.

A mature decision is not "we have backups." It is "we can recover this workload, to this point, within this time, through a tested path that survives the failures we designed for."