Comparison
Recovery point objectivevsRestore testing
Recovery point objective
backups run nightly, so recovering means losing up to a day of writes, and nobody outside the platform team knew that.
The maximum acceptable data loss, expressed as time: how far back you may be forced to rewind. It is set by replication and backup frequency, so nightly snapshots mean a day and synchronous replication means approximately none. It is the number people conflate with recovery time, and the two are independent — you can be back in ten minutes having lost a day, or take a day to restore losing nothing.
Full entry →Restore testing
you restore the backup into a scratch environment on a schedule, because a backup nobody has restored is a hypothesis.
Regularly performing a real restore from backups and verifying the result, rather than trusting that the backup job exited zero. It routinely uncovers backups of the wrong database, encrypted backups whose key is gone, restores that take far longer than the objective, and permissions that only exist in the environment being replaced. It is the single highest-value reliability exercise available and the most commonly skipped.
Full entry →