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.