Disaster recovery planning and test-restore checklist

In short

A backup only counts if you can restore from it when it matters. For each client, decide what must come back and how fast, make sure the backups and credentials you'd need are in place, and prove it with regular test restores. Use this checklist when you onboard a client and at every review.

How it works

1. Agree what "recovered" means

List the client's critical systems and data: file shares, line-of-business databases, the accounting file, Microsoft 365 mailboxes and sites, key laptops.
For each one, agree two numbers with the client: how much recent data they could afford to lose (this sets how often you back up), and how long they could be without it (this sets the restore method).
Write the plan down in your documentation system, and review it when the client adds systems or staff.

2. Match the protection to the plan

Whole-machine recovery for servers and critical workstations: a Disk Image Protected Item, or an agentless VM backup. See VM backup methods: agentless vs. inside the guest.
Fast file restores: a Files and Folders Protected Item for the data, even when the machine also has an image. See Back up files and folders and Best Practices.
Applications and databases: the matching Protected Item type, for example Microsoft SQL Server.
Microsoft 365: a Microsoft Office 365 Protected Item. Microsoft's own retention isn't a backup. See Office 365 - Overview.
Schedules that meet the data-loss target, with If the last job was Missed on for laptops. See Backup schedules explained.
Retention long enough to go back before a problem was noticed, for example ransomware that sat unnoticed for weeks. See Retention policies and retention passes.
A second copy where the plan needs a fast local restore, for example a Storage Vault on an external drive or NAS alongside the cloud vault. See Creating Storage Vaults.

3. Secure the keys to the backups

Backups are encrypted with keys protected by the client's user account password. If the password is forgotten and Allow administrator to reset password is off, you can't reset it from the Web Portal, and without it the backups can't be decrypted. That setting can't be turned back on remotely once the client turns it off. Store each client's backup credentials in your password manager. See Encryption and key management.
Turn on two-factor authentication for your own Web Portal sign-in. See Configure two-factor authentication.
Protect backups from deletion by someone using a stolen login: use a policy that prevents deleting Storage Vaults and snapshots, and stops Protected Items overriding retention. See Policy Settings and Ransomware protection.

4. Prepare the recovery tools in advance

Make recovery media for each client that has Disk Image backups, and keep it with their documentation. See Recovery Media.
Know where you'd restore a server if its hardware were gone: spare hardware, a Hyper-V, VMware or Proxmox host, or a cloud VM. See Restore a backup as a virtual machine.
For very large restores over slow links, know that Restore Via Mail is available.

5. Watch every job

Check Management Console > Recent activity and Job logs for errors, warnings and missed jobs. See Job logs, recent activity and job statuses explained.
Set up email reports or alerts so failures come to you. See Email Addresses and Monitoring and PSA/RMM integrations overview.

Test-restore checklist

We suggest testing every client at least once a quarter, and after any big change such as a new server or a new backup type. Record the date, what you restored and how long it took.

File test: restore a few files the client names to a new folder and have them open them. See Restore files and folders.
Integrity test: run Simulate restore only on each important Protected Item. It reads and rebuilds the whole backup without writing it to disk. See Run a test restore.
Image or VM test: restore a critical server as a VM on an isolated network and check it boots and its applications start. See Restore a backup as a virtual machine.
Granular test: pull one file out of an image or VM backup. See Restore single files from image and VM backups.
Microsoft 365 test: restore one mailbox folder or document to a test location. See Office 365 - Restore.
Credentials test: confirm you can sign in to the client's user account with the stored password.
Recovery media test: boot the recovery media on the client's hardware (or a similar machine) and check it sees the network and the disks.
Timing: compare how long each restore took with the downtime target you agreed. If it's too slow, change the method, for example add a local vault.

What this means for you

A tested plan turns a disaster into a routine job, and the test records show the client what they're paying you for.
Test restores download data. Run big ones outside business hours, or use a speed limit on the client's connection.
Delete restored test data afterwards, and keep test VMs off the production network.