Restore test schedule
Why a schedule, and not just “we take backups”
Section titled “Why a schedule, and not just “we take backups””A backup is a belief until somebody restores it. The failure mode is well known and quiet: backups run green for a year, and the first restore anyone attempts is the one that has to work.
So the thing worth publishing is not the backup frequency. It is how often the restore is rehearsed, and what the last rehearsal produced.
What counts as a rehearsal
Section titled “What counts as a rehearsal”A run only counts here if it produces all four:
- A restore that actually ran — not a check that a backup file exists.
- A named outcome — PASS or FAIL, not “completed”.
- A verification step — something read back from the restored system, so the result is evidence rather than an absence of errors.
- Any finding it surfaced, including the ones that make us look unprepared. Those are the whole return on doing it.
The record so far
Section titled “The record so far”| Rehearsal | Type | Outcome |
|---|---|---|
| Platform database recovery | Point-in-time restore, end to end | PASS |
| Alerting | Failure condition provoked, alert observed firing (Sev 1) | PASS |
Finding carried forward from the restore drill: a restored database server does not inherit the original server’s firewall rules. A restore can therefore succeed at the data layer and still leave an application unable to connect — which is the kind of thing only a rehearsal finds, and precisely the reason to hold one.
Cadence
Section titled “Cadence”Recovery rehearsals are run at least once per release cycle, and additionally whenever a change touches the recovery path itself — the database tier, the backup configuration, or the restore procedure.
We are stating the trigger rather than a date on a calendar, because a fixed date that slips tells you nothing about whether the rehearsal happened, while a trigger tied to what changed is checkable against the change itself.
What this page does not say
Section titled “What this page does not say”- It does not claim a rehearsed zone failover. The database’s zone redundancy is read as healthy; a failover has not been staged. See Business continuity.
- It does not claim that a merchant-initiated restore has been drilled separately from the platform-level one.
- It does not convert these rehearsals into an RTO or RPO figure. The drill proved the path works; it was not timed to a target, and inventing one from it would turn evidence back into a guess.