Backup, Recovery, and High Availability
This domain tests recovery-point and recovery-time design: NDB SLAs, snapshots, log backups, point-in-time recovery, clones, and the boundary between storage redundancy and database-level high availability.
Rules
- A snapshot alone gives a crash-consistent or application-consistent copy at a point in time. Point-in-time recovery requires log backups or archive logs in addition to snapshots.
- NDB SLAs define snapshot frequency, log catch-up frequency, and retention. Retention controls how far back you can recover.
- Clones create independent database copies for dev/test from a snapshot or time machine, without affecting the source.
- Nutanix redundancy factors (RF2/RF3) protect against disk or node failure. Engine-native HA (Oracle Data Guard, SQL Server availability groups, PostgreSQL streaming replication) protects against database or site failure. They are complementary.
Worked example
An application needs RPO of 15 minutes and RTO of one hour. Configure hourly snapshots with 15-minute log catch-up and a retention window covering the maximum acceptable recovery age. Reasoning: snapshots alone could lose up to an hour; log catch-up reduces RPO to the log interval. A one-hour RTO requires a tested restore or clone procedure, not just a backup policy. Validate by restoring to a point in time and running application checks.
Traps
- Claiming PITR from snapshots without log backups.
- Assuming NDB HA replaces Data Guard or availability groups.
- Testing backup success but never testing restore time.
- Letting retention delete the logs needed for the agreed recovery window.