24 controls · 9 fields · Public CSV · No signup

Backup restore test checklist for MSPs.

A successful backup job is not recovery evidence. Use these 24 checks to run a controlled restore drill, verify the recovered data and permissions, measure the recovery path, document every exception, and leave production data untouched.

Download the CSV checklist Use restore proof in client onboarding Add restore testing to the onboarding checklist Review Nizlo backup capabilities Compare RMM with backup Plan endpoint and recovery evidence for insurance-agency IT Add restore tests to the service cadence Print this checklist

1. Authorize and scope

  1. Record the client, protected system, data owner, restore-test owner, approver, business purpose, and test date.
  2. Define the recovery objective being tested: file, folder, application data, configuration, image, or full-system recovery.
  3. Document recovery point and recovery time targets, plus the exact evidence that will prove each target.
  4. Confirm that the test destination is isolated, has sufficient capacity, and cannot overwrite or expose production data.

2. Select recovery evidence

  1. Choose a representative recovery point and record its timestamp, job identifier, retention tier, source endpoint, and protected scope.
  2. Confirm that the recovery point completed without unresolved warnings, missing sources, stale credentials, or retention exceptions.
  3. Select known test artifacts with expected hashes, sizes, dates, owners, permissions, and application meaning.
  4. Record encryption, key, MFA, approval, network, and technician-access dependencies before the restore begins.

3. Restore safely

  1. Start the restore through the approved workflow and capture actor, source, destination, start time, selected items, and job identifier.
  2. Use a separate recovery folder, isolated host, sandbox, or alternate location unless the approved test explicitly requires an in-place restore.
  3. Stop when the selected tenant, endpoint, recovery point, destination, permissions, or item count differs from the approved scope.
  4. Capture transfer progress, warnings, retries, throttling, failures, completion time, and any manual intervention.

4. Validate the result

  1. Verify expected files, folders, or application objects exist and reconcile counts, sizes, timestamps, and paths.
  2. Compare hashes or another byte-level integrity signal for representative files when the data type permits it.
  3. Open representative recovered content with an appropriate application and confirm it is usable, not merely present.
  4. Validate ownership, access-control lists, inherited permissions, encryption state, metadata, links, and required application dependencies.

5. Measure recovery

  1. Calculate recovery time from authorized start through usable validation, separating queue, transfer, repair, and application-check time.
  2. Compare the restored recovery point with the target data-loss window and explain any gap or excluded source.
  3. Test whether documented escalation, vendor support, alternate media, credential recovery, and failover contacts work when a dependency fails.
  4. Record performance limits, bandwidth effects, storage requirements, egress costs, licensing constraints, and operational bottlenecks observed.

6. Close the drill

  1. Remove test data from the recovery destination under the approved retention and disposal procedure without altering the protected source.
  2. Log every failed, partial, slow, inaccessible, or unverifiable result with an owner, risk, compensating control, due date, and retest condition.
  3. Update the recovery runbook, protected scope, credentials, contacts, capacity assumptions, and test cadence from observed evidence.
  4. Close only when the approver accepts the evidence, exceptions are owned, sensitive test data is disposed, and the next restore test is scheduled.

Definition of a successful restore test

A restore test succeeds when an authorized recovery point produces the expected usable data in a safe destination; integrity, permissions, dependencies, recovery timing, and data-loss timing are measured against defined targets; production remains protected; and every exception has an owner and a retest path. A green backup-job status alone is not proof of recoverability.

Backup restore test questions

What should a restore test verify?

Verify scope, recovery point, isolation, object counts, content integrity, permissions, application usability, RPO and RTO evidence, exceptions, cleanup, and approval.

How often should an MSP test restores?

Set the cadence from workload criticality, client commitments, recovery objectives, change frequency, prior failures, and risk, then schedule the next test at closure.

Does a successful backup job prove recoverability?

No. A green job does not prove that the data can be restored safely, opened, reconciled, timed, and accepted.

Is the checklist free?

Yes. The page and nine-field CSV are public and ungated and require no account or email address.