Backup Restore Drills
A backup nobody has restored is a hope, not a backup. A restore drill restores the newest database backup into a separate database, times it, checks what came back and records the result.
Restore drills are a control of the AWRA service itself, not a workspace setting. They are run by whoever operates the deployment, and the results page is visible to the system owner only. This article explains what a drill checks, so you can ask for the evidence in a security review.
What A Drill Does
- Takes the newest database backup file.
- Restores it into a separate scratch database — never the live one — and times the restore.
- Compares what came back with the live database, records the result, then empties the scratch database again.
Drills are off until the deployment names a scratch database and switches them on. Once on, a drill runs every Sunday, and the operator can also run one on demand.
When A Drill Passes
- The import finished cleanly.
- The core tables — organizations, users, roles, permissions and migrations — came back and are not empty.
- The backup holds at least 90% of the live tables, so a dump cut short by a full disk fails.
- The restore finished within the recovery time objective, 60 minutes unless the deployment sets another figure.
The Two Numbers
- Recovery time (RTO) — how long the restore took.
- Recovery point (RPO) — how old the backup was when the drill started, which is how much work a restore at that moment would lose.
Each drill also records row counts for items, customers, vendors, purchase orders, invoices and audit entries beside the live counts, for the record.
Need help with this topic?
Capture the module, record number, branch or warehouse, user, visible message, and what you expected to happen before contacting support.