Every organisation that has lost data had backups. The failure is almost never that no backup ran; it is that the backup did not contain what was needed, or could not be read, or took far longer to restore than anyone had assumed.
A green tick in a backup console confirms that a job completed. It does not confirm that the data is consistent, that the encryption key is available, that the retention covers the period you need, or that the restore path works. Only a restore confirms those things.
Run the drill on a schedule. Quarterly is a reasonable cadence for most organisations: pick a system, restore it to an isolated environment, and verify not just that files appeared but that the application starts and the data is coherent. Databases in particular can back up successfully and restore into an inconsistent state.
Time it. Recovery time objectives are usually written as aspirations and rarely measured. A drill produces a real number, and that number is often several times the stated objective. Discovering this in a drill lets you either change the architecture or change the commitment — both honest options, unlike discovering it during an incident.
Test the scenario where your primary environment is unavailable, including the tooling. If the credentials to your backup system live in a password manager hosted in the environment that is down, or the runbook is on the file share you are trying to restore, the drill will surface that in a way no design review does.
Ransomware changes the requirement. Backups reachable from the compromised environment with the compromised credentials are encrypted alongside everything else. At least one copy must be immutable or genuinely offline, and the drill should include restoring from that copy specifically, since it is often the path nobody has exercised.
