Backups and Restore: Recovery Must Be Proven

People often say "we have backups" as if the presence of copied files settles the question of recovery.

It does not.

A backup is an independent recoverable copy. Restore is the tested process of rebuilding usable data or a working system from that copy.

A backup that cannot be found, decrypted, read, or applied within the required time is not a reliable recovery plan.

A concrete example: the missing encryption key

Imagine a company copies its database every night and encrypts each backup. Months later, the production database is damaged.

The backup files exist, but the only encryption key was stored on the failed server.

The copies are mathematically protected and operationally useless.

This example shows why recovery depends on the entire chain: data, keys, software, documentation, permissions, infrastructure, and practiced people.

Backups address multiple failure types

Recovery plans should consider:

• Accidental deletion
• Incorrect application changes
• Ransomware
• Storage failure
• Database corruption
• Lost device
• Regional outage
• Insider misuse
• Natural disaster

One backup design may not handle every event.

A continuously synchronized replica helps with hardware failure, but it may immediately replicate an accidental deletion. A historical backup preserves an earlier state.

Backup is not synchronization

Synchronization keeps locations aligned. When a file changes or disappears, the change may propagate everywhere.

A backup preserves recoverable versions across time.

Likewise, RAID or disk mirroring improves availability when hardware fails but does not protect against:

• Accidental overwrite
• Malicious deletion
• Logical corruption
• Credentials used by an attacker

Replication, synchronization, snapshots, and backups can all contribute to resilience, but they solve different failure modes.

Recovery point objective

The recovery point objective, or RPO, defines how much recent data loss is acceptable.

If backups occur every 24 hours, a failure just before the next backup could lose almost a day's work. That may be acceptable for a personal archive but disastrous for payment records.

An RPO of five minutes may require transaction-log shipping, continuous replication, or frequent incremental backups.

RPO is a business requirement expressed in time, not simply a technical setting.

Recovery time objective

The recovery time objective, or RTO, defines how quickly service must be restored.

A backup stored on inexpensive archival media may be durable but take many hours to retrieve. A standby database may recover quickly but cost more to operate.

RTO influences:

• Storage tier
• Automation
• Standby infrastructure
• Team availability
• Restore tooling
• Data volume and network capacity

Recovery time should include validation and application startup, not only copying bytes.

Full, incremental, and differential backups

A full backup copies the complete protected dataset.

An incremental backup copies changes since the previous backup of any kind. It minimizes daily storage and transfer, but restoration may require a chain of increments.

A differential backup copies changes since the last full backup. Each later differential grows, but restore generally needs the full backup plus only the latest differential.

Databases may also archive transaction logs for point-in-time recovery.

The best method depends on data size, change rate, recovery goals, and tool reliability.

Snapshots are fast but need context

Storage snapshots capture a volume or dataset at a point in time, often efficiently.

However, a snapshot taken while an application writes related files may be crash-consistent rather than application-consistent. The application must be capable of recovering from that state, or writes may need to be paused or coordinated.

Snapshots stored in the same account and controlled by the same credentials can also be deleted by the same compromise.

Treat snapshot behavior as a documented guarantee, not an assumption.

The 3-2-1 principle

A common starting guideline is:

• Keep at least three copies of data.
• Use two different storage types or failure domains.
• Keep one copy off-site or otherwise isolated.

Modern plans may add an offline or immutable copy.

The numbers are not a complete architecture, but the principle reduces the chance that one event destroys every copy.

Isolation matters. Copies in different folders on one failing disk are not independent.

Immutability limits destructive changes

An immutable backup cannot be changed or deleted during a defined retention period, even by ordinary administrative actions.

This can reduce ransomware and insider risk. Effective immutability requires:

• Correct retention configuration
• Separate administrative control
• Protected credentials
• Monitoring
• Tested access when recovery is needed

Immutability prevents deletion, but it can also preserve sensitive data longer than desired. Retention must align with legal and privacy requirements.

Restore tests provide evidence

A useful restore test:

1. Starts in a clean isolated environment.
2. Retrieves the selected backup.
3. Obtains required keys and credentials.
4. Rebuilds data and services using documented steps.
5. Validates integrity and application behavior.
6. Measures actual recovery time and recovered point.
7. Records problems and improves the process.

Checking that a backup job reported success proves only that the job completed its own steps.

The real question is whether the organization can recover.

Validate restored data

A restore may finish without obvious errors while containing incomplete or inconsistent data.

Validation can include:

• Checksums
• Expected record counts
• Database integrity checks
• Referential constraints
• Sample application queries
• Authentication tests
• Comparison with known business totals

For a full system, also confirm configuration, file objects, search indexes, queues, and external dependencies.

Recovery of one database may not restore a coherent application if related systems come from different points in time.

Documentation and ownership

A recovery plan should identify:

• Protected systems and data
• Backup schedule and retention
• Storage locations
• Key ownership
• RPO and RTO
• Restore commands and prerequisites
• Decision authority during an incident
• Communication responsibilities
• Last successful restore test

Documentation must be available when primary systems are unavailable. A recovery guide stored only inside the failed environment is not enough.

Backups need monitoring

Monitor:

• Missed or failed jobs
• Unexpected backup size
• Corruption checks
• Replication lag
• Retention expiration
• Unauthorized deletion attempts
• Restore-test age

An unchanged tiny backup may indicate that a source stopped being included. A successful status is only one signal.

Regular review is necessary as systems, schemas, encryption keys, and staff change.

Knowledge check

1. Why is a synchronized replica not a complete backup?
2. What is the difference between RPO and RTO?
3. How do incremental and differential backups differ?
4. Why can a storage snapshot be inconsistent for an application?
5. What does a restore test prove that a successful backup job does not?

The one idea to remember

A backup is a promise about future recovery. Only an isolated, complete, and regularly tested restore can provide evidence that the promise is real.