Backup Restore Testing
Periodically performing a full restore and measuring it, on the basis that an untested backup is a hypothesis rather than a capability.
Backups fail silently and in predictable ways: the job succeeded but excluded a filesystem added last year, the encryption key is unavailable, the archive is corrupt, the retention window rolled past the point where the corruption started, or the restore takes eleven hours against a recovery objective of two.
None of these are detectable from a backup job's success status, and all of them are detectable by restoring. The practice is therefore to restore on a schedule, into an isolated environment, with a timer running and a verification step confirming the data is usable rather than merely present.
The measurement matters as much as the exercise, because restore time is the number that determines whether the recovery objective is real. It scales with data volume in ways teams do not anticipate, and it usually gets worse quietly as the database grows.
The scenario to include beyond hardware failure is the one that most tests omit: recovery from corruption or malicious deletion, where the most recent backups contain the problem and you must restore to a point before it. That requires knowing when the damage started, and it requires backups that an attacker who compromised the production environment could not also delete — immutable retention, a separate account, and separate credentials.
The uncomfortable question worth asking in any review: when did you last restore this system completely, and how long did it take? A recovery objective without a measured restore behind it is a number in a document.