Use the evidence and practical questions in this article to test your own assumptions. Any worked examples use hypothetical inputs.
A completed backup is not a completed recovery
A backup report shows that a copying process ran; it does not prove the business can resume work. CISA’s ransomware guidance stresses protected backups and testing. For a US small business, begin with the functions that must return first: orders, payroll, customer records or a production schedule. Name the application, files, credentials and people each function needs. Set a recovery-time objective and a tolerable data-loss window in business language. Those goals help determine backup frequency and architecture, but they must be tested against the actual system rather than treated as promises.
Run a contained restoration exercise
Choose a representative record set and restore it to an isolated environment approved by the administrator. Avoid overwriting production data during a test. Check that files open, permissions are correct and the application can read the recovered information. Record when the request begins, when the data is available and when a user completes a normal task. Those are different milestones. If recovery depends on an external provider, include its response and approval steps. Preserve evidence of the result without exposing customer information in an unsecured test folder.
Choose recovery targets by discussing the lost work the company can tolerate. An application used continuously may need a different backup schedule from a rarely changed reference archive. Document that distinction instead of giving every system an identical target.
Fix the dependency that made the test fail
A hypothetical office may restore its documents quickly but remain unable to work because its account administrator is unavailable. Another may discover that encryption keys were stored only on the lost machine. Add those dependencies to the recovery plan and repeat the relevant test after correction. Review whether backup copies can be altered by the same credentials that control production. Retention, isolation and access should be deliberate choices. Schedule tests after major application changes and record a responsible owner for unresolved findings. The useful metric is demonstrated restoration of a business function, not the amount of storage purchased.
- Define critical functions, recovery time and acceptable data loss.
- Restore safely and ask a user to complete real work.
- Record failures, owners and the next verification date.
Image source and usage
The interior of a StorageTek tape library at NERSC
Derrick Coetzee from Berkeley, CA, USA
Source image · Image-use terms
Web versions are resized and compressed; attribution and applicable source terms are retained.
Frequently asked questions
Is file synchronization the same as a protected backup?
Not necessarily. Deletions or harmful changes may synchronize too; review versioning, isolation and restoration.
Should a recovery test overwrite live business records?
Use an administrator-approved isolated test environment to avoid damaging production.
Sources & further reading
Source links checked October 20, 2026. Rules and availability may change; verify current terms directly. Read our editorial standards.



