[Blog]()Business 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. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** Test a backup by restoring it to an isolated environment and completing a realistic operation with its files and access. Measure from outage declaration until the business can work, and identify transactions missing from the recoverable point. Agree beforehand how much loss and downtime each process can tolerate. ## 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. [Download CSV worksheet]() In this guide - [Define tolerable loss and time by process]() - [Fictional example: a 09:30 copy and a 10:00 interruption]() - [Recover a complete operation without affecting production]() - [Measure until the outcome is useful to the business]() - [Leave a procedure another person can follow]() ## 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. ## Review a complete recovery drill Using your backup inventory and an anonymized critical operation, review what must recover alongside the database. A free consultation helps define tolerable loss, how to verify the return, and who authorizes resuming work. - Backup, file and access-owner inventory - One critical operation with an anonymized document and attachment - Tolerable loss and interruption for that process [Book a free consultation]()[Ask on WhatsApp]() Related - [Cybersecurity for businesses]() - [Hosting, backups and maintenance]() ## Frequently asked questions ### How often should we test restoration? 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. ### Can we test on the active system? 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. ### What if the backup is encrypted? 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. ### Does a 30-minute RPO mean losing exactly 30 minutes? 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 1. [Restore testing]()AWS 2. [Plan for Disaster Recovery]()AWS Last updated: October 8, 2026 ## Keep reading [System cutoverOct 8, 2026 ### Changing systems: rehearsal, cutover and rollback conditions]()[Access controlOct 8, 2026 ### Employee offboarding: accounts, sessions and integrations to review]()[SecurityOct 2, 2026 ### Who holds the digital keys to your business? How to check your access]() --- Canonical: https://nightlysoftware.com/en/blog/backup-restore-test Updated: 2026-10-08 Description: Check whether you can recover data, files and a complete business operation. Set tolerable loss and downtime with a practical restore-test worksheet.