Starting from recovery objectives
Design starts with RPO (acceptable data loss) and RTO (acceptable downtime). Both numbers are set with the business, and technology is chosen afterwards. A single objective is never applied across every system — each criticality class gets its own.
- Objectives are signed off by the business owner
- Separate RPO and RTO per criticality class
- Systems that cannot meet their objective are listed openly
- Cost rises steeply as objectives tighten — said up front
Layered retention and immutable copies
Copies never live in one place. A layer close to production for fast return, a layer in a different location, and an immutable layer against ransomware are designed together. The isolated copy is reached through an identity path separate from production.
- Immutable copies reject deletion and encryption attempts
- The isolated copy uses a separate identity path
- Retention is matched to legal and business requirements
- Copy count and location are visible in one table
Restore testing and evidence
Restore capability is measured through scheduled tests. A test runs at application level, not file level: does the system come up, does it find its dependencies, is the data consistent. The result is recorded with its evidence.
- Restore tests run at application level
- Measured duration is reported against the objective
- A failed test produces a remediation item
- Evidence is usable in audit and insurance processes
Archiving and lifecycle
Backup and archive are not the same thing. Backup exists for return; archive exists for retention obligations. They are governed by separate policies — otherwise data past its retention period keeps living in backups, generating both cost and risk for nothing.
- Separate policy and separate duration for backup and archive
- Expired data is destroyed on a planned basis
- Archive access is designed to be slow but complete
- Destruction is recorded