BlogBusiness continuity
A backup is not enough: testing restoration, data loss and return time
A “backup successful” notice does not prove you can look up, enter and deliver work tomorrow. Rehearse complete recovery.
Test worksheet: Backup restore tests: recovery, RPO and RTO
A “backup successful” notice does not prove you can look up, enter and deliver work tomorrow. Rehearse complete recovery. Record inputs, expected outcome, evidence, owner and observed result.
Define tolerable loss and time by process
A retailer may need to resume checkout before historical reporting; a service company may need work orders and files before dashboards. A recovery point objective, RPO, expresses tolerable data loss in time. A recovery time objective, RTO, expresses tolerable interruption. These are targets to agree and test, rather than guaranteed properties of a backup.
AWS Well-Architected separates availability from disaster recovery and recommends defining loss and downtime objectives. AWS Backup offers restore testing and duration monitoring. A completed restore job still needs your business validation: the correct data must be present and the required process must work.
Fictional example: a 09:30 copy and a 10:00 interruption
A maintenance company agrees on a 30-minute RPO and 90-minute RTO for active work orders. In rehearsal it declares an outage at 10:00 and restores the 09:30 point. The team can complete an order at 11:35: 95 minutes have elapsed, so it misses the time target. These synthetic figures explain the calculation and are not measurements of a Nightly service.
Finding the database is not enough. Orders entered between 09:30 and 10:00 must be identified as potentially missing, and the team must know whether another authorized record can reconstruct them. If restored attachments are from 09:00, evidence loss exceeds database loss. Verification should state that difference rather than describing everything as one successful backup.
| Component | Verification | Dependency to record |
|---|---|---|
| Database | Orders and movements through the recovery point | Version and consistency |
| Files | Attachments open and belong to the correct orders | Location and permissions |
| Access | An authorized user can complete work | Identity and administrative recovery |
| Integrations | Tasks restart with a defined replay boundary | Keys, queues and provider |
Recover a complete operation without affecting production
Use an authorized isolated destination. Disable real messages, payments and connectors during rehearsal to prevent external effects. Record backup identifier, dates, owner and dependencies. Do not copy passwords or keys into a shared worksheet; record their custodian and how authorized access is obtained through the agreed procedure.
| Case | Expected result | Evidence |
|---|---|---|
| Restore the 09:30 copy | Consistent data in an isolated destination | Identifier and job record |
| Open an order and attachment | Correct file with authorized access | Reference and file review |
| Find a 09:50 movement | Absence acknowledged with a reconstruction plan | Time and reference comparison |
| Restore account lacks permission | Visible failure without claiming recovery | Error and access owner |
| Retry a failed restoration | Clean destination or controlled state without mixed versions | Timeline of both attempts |
| Restart a queued task | One authorized execution without duplicate messages | Task reference and outcome |
Measure until the outcome is useful to the business
Separate detection, decision, transfer, restoration and validation time. This helps fix the relevant bottleneck. A fast download does not compensate for waiting an hour for the only access approver. Record the observed result and reason for a missed target; changing the target afterward does not make the test pass.
Restoration depends on provider, file sizes, encryption, permissions and compatible versions. A sample rehearsal can teach the team, but it does not prove recovery of the full operation. Repeat when those dependencies change and retain earlier results. Agree how long to retain backups and evidence according to business needs and applicable obligations.
Leave a procedure another person can follow
Include an alternate contact, stop conditions and an access check independent of the usual owner. Review control of your digital keys, employee offboarding and access and the cutover and rollback plan. An inaccessible copy or missing owner does not resolve continuity.
The worksheet contains fictional inputs and empty fields for your rehearsal. Bring a backup inventory, one priority process and downtime tolerance to a free consultation about hosting and maintenance. The first step is checking what current configuration and access can demonstrate, rather than assuming instant recovery.
Frequently asked questions
Agree a frequency based on the effect of failure, and retest after important changes to data, infrastructure, encryption or owners. Backup frequency and rehearsal frequency are separate decisions. A daily backup notice does not replace periodic testing of usable recovery.
A rehearsal normally uses an isolated destination with external connections disabled and authorized access. Restoring over an active system can replace real work. Any test with operating impact needs a specific operation and recovery plan.
The rehearsal must show that an authorized person can obtain the key through the planned procedure. Having a file you cannot decrypt does not demonstrate recovery. The worksheet records custody and dependencies, never the secret itself.
No. It is a target for tolerable loss. Observed loss depends on the last consistent recoverable point and all required sources, including attachments. Compare identified transactions and dates rather than inferring loss from the backup schedule alone.
Sources
Last updated:
