Configured database backup retention as infrastructure‑as‑code, then audited the recovery position and documented the restore procedure — naming the remaining gaps rather than leaving them to be found during an incident.

Situation. A product that lives on its data can’t afford to lose any, and “there are backups somewhere” is a hope, not a recovery plan. The only backup worth having is one you know restores, into an environment you know you can rebuild. NextMariner had neither half written down.

Task. Get the recoverable position defined instead of assumed — the data, the environment around it, and an honest account of how far that actually reaches today.

Action. Backup retention is configured in the Bicep beside the database it protects, so point‑in‑time restore is a property of the template rather than a setting someone once clicked in a portal. The environment around it is defined as infrastructure‑as‑code too, which is the quiet half people forget: restoring a database into an environment you’d have to rebuild by hand from memory isn’t really recovery. Then the position was audited and written up — the restore procedure, the drill that would measure it, and the gaps still open: geo‑redundancy is switched off, and the recovery‑time objective is proposed rather than measured, because no drill has been run yet.

Result. Recovery stopped being a vague reassurance and became a documented position with its gaps named. That reads less impressively than “disaster recovery: done”, and it is worth considerably more — whoever touches it next knows what is covered, what isn’t, and exactly which drill closes the difference. A named gap is one you can close; an unnamed one is discovered during an incident.