Write my database disaster recovery plan and then run one drill to validate it. Assume the scenario: the primary database is gone or corrupted beyond trust, right now. Document: where backups live and who can access them (including whether access survives the hosting account being locked out); the exact step-by-step restore procedure, written for someone tired and stressed, with the actual commands and where to run them; the recovery point objective (how much data loss is acceptable: last hour, last day) and recovery time objective (how long the app can be down), with the current backup setup measured against both; and the order of operations after restore: what gets verified before traffic returns (row counts, spot-check recent orders, run the app's critical paths). Then run the drill: restore the latest backup to a scratch environment, time it, verify the data, and write down what actually happened versus the plan. Fix the plan where reality disagreed. Don't test restores against production. Don't assume managed-host point-in-time recovery works; verify it once. Deliver: the runbook, the drill results with timings, the gap list (where current setup misses the stated objectives), and the changes applied to close the gaps.