Start with two objectives per application
The recovery point objective is how much recent data the business can afford to lose, expressed as time. The recovery time objective is how long the service can be unavailable. Different applications have different values, and the backup design follows from them, not from a single policy applied to everything.
Group applications into recovery tiers
| Tier | Objective profile | Typical technique |
|---|---|---|
| A | Very little data loss, rapid recovery | Synchronous or near-synchronous replication, with backup as a separate protection |
| B | Limited data loss, recovery within hours | Frequent snapshots or asynchronous replication plus regular backup |
| C | Daily recovery point acceptable, recovery within a day | Scheduled backup to disk with off-site copy |
| D | Long recovery acceptable | Backup and archival, possibly tape |
Replication is not backup: it copies corruption and deletion as faithfully as good data. Both are usually needed for important systems.
Size the backup window and the bandwidth
The time needed for a backup is the data to be moved divided by the throughput that is actually achievable, which depends on source performance, network and the backup target, not on the rated speed of the fastest component.
As an illustration only: a 20 TB full backup at an effective 400 MB/s takes about 50,000 seconds, nearly 14 hours. An incremental backup of 5% daily change, 1 TB, at the same rate takes about 2,500 seconds, roughly 42 minutes. If the window is shorter than the full backup, the design needs different technique, such as snapshot-based backup, parallel streams or a change in schedule, not an optimistic assumption.
Size storage for retention and growth
- Retention period for each class of data, driven by operational and regulatory need.
- Data growth rate and daily change rate.
- Effect of deduplication and compression, assumed conservatively and checked with measured data.
- Space for several full backups, incrementals, and any immutable or off-site copies.
- Replication traffic to the second site, and the link capacity it requires.
Protect the backups from the events they exist for
Keep at least one copy off the production system and out of reach of production credentials. Immutable or offline copies protect against deletion and encryption by an attacker. Backup administration accounts should be separate from general administration, and backup catalogues and keys must themselves be recoverable.
Back up applications consistently
A copy of files that are being written is not necessarily a usable database. Use application-consistent methods, such as database-aware backup agents or quiesced snapshots, and capture logs where point-in-time recovery is required.
Know the order of recovery
Applications depend on identity, name resolution, networks, databases and one another. Document the order in which services must be restored and test it. Recovery of the backup system itself, including its catalogue and credentials, is part of the plan.
Test restores on a schedule
A backup is only proven by a restore. Test restoration of files, of full systems and of whole applications in an isolated environment, record the time achieved against the recovery time objective, and review results after any change to the platform.