Data Resilience
Data Resilience tests how you design, operate, and prove recovery of business data across on-premises, virtual, and cloud workloads. Expect RPO/RTO mapping, immutable retention, replication topology, and restore validation rather than simple backup-job creation.
Core rules
- Start from business impact: tier applications, assign RPO as maximum tolerable data loss and RTO as maximum tolerable downtime. Backup frequency must meet RPO; restore throughput must meet RTO.
- Apply 3-2-1-1-0: three copies, two media types, one offsite, one immutable or offline, and zero unverified errors.
- Immutability and retention lock defend against deletion and encryption. Snapshots alone are not a backup when they share the same admin plane or fail with the source.
- Replication improves availability, not history. Keep independent recovery points and test them.
- Restore to an isolated network and validate application consistency, not just VM power-on.
Worked example
A payroll application has RPO 15 minutes and RTO 2 hours. Hourly VM snapshots miss the RPO, so use 15-minute CDP or frequent snapshots plus a replicated copy. Retain 35 daily restore points with a 7-day immutable lock. Payroll depends on a database and app server, so restore the database first, mount it, then restore the app and run a synthetic transaction. Measure the restore: if it takes 2.5 hours, add a warm standby or a faster recovery target.
Traps that cost marks
Treating replication as backup. Setting retention without legal or regulatory review. Restoring the newest point without a corruption check. Forgetting dependency order. Never measuring restore time.