Backup restore test checklist: a quarterly plan and sign-off sheet

Why a backup report is not enough

Backup software reports that a job finished. It does not report that the job still covers the new server added in March, that the service account lost its permissions after a password change, or that the restore needs a licence key nobody can find. Those problems only show up when you try to restore. The reasons are covered in more depth in why untested backups fail; this page is the working template.

Before testing, write down two numbers for each important system, agreed with the people who use it:

• RPO (recovery point objective): how much recent work you can afford to lose. A four-hour RPO means backups at least every four hours.
• RTO (recovery time objective): how long the system can be down before the damage is unacceptable.

If you have not set these yet, the disaster recovery planning guide explains how. Without them, a restore test has nothing to pass or fail against.

The quarterly test plan

Rotate through your systems so that every critical one gets a full restore at least once a year. A typical year for a 50 to 200 person company looks like this:

• Every month (about an hour): restore a handful of files from different shares and one mailbox folder to a test location. Open them. Check dates.
• Quarter 1: full restore of the file server or main SharePoint sites, plus a Microsoft 365 mailbox and a OneDrive.
• Quarter 2: full restore of the ERP or accounting database to an isolated test server. Finance runs a trial balance against a known figure.
• Quarter 3: restore a whole server (domain controller or line-of-business application server) from the off-site or cloud copy, not the local one.
• Quarter 4: tabletop exercise of a full outage, usually ransomware, plus a restore of whichever system failed or ran slowest earlier in the year.

What to test, system by system

Files and shared folders

• Restore a folder from yesterday and one from the oldest point you keep. Both should open.
• Check file permissions came back with the files.
• Confirm new shares created this year are in the backup scope.

Mailboxes

• Restore a single deleted email, a folder and a full mailbox to a test account.
• Include a mailbox of someone who has left. Leavers' mailboxes are often dropped from scope when the licence is removed.

Microsoft 365 (OneDrive, SharePoint, Teams)

• Restore a OneDrive folder to a point before a simulated mass change.
• Restore a SharePoint document library and a Teams channel's files.
• Confirm the backup uses its own credentials and would still work if a global admin account was compromised.

Servers and virtual machines

• Restore the whole machine to an isolated network so it cannot clash with the live one.
• Check it boots, services start, and a user can log in and do a normal task.
• Restore at least once a year from the off-site or immutable copy. That is the copy you will need after ransomware.

ERP and accounting database

• Restore the database and the application to a test server, at the version you run in production.
• Ask finance to check the restored data against a figure they know, such as last month's closing balance.
• Note anything the restore depended on: licence files, encryption keys, the vendor's support portal, a person's memory.

Recording the result: the sign-off sheet

Use one row per test. This is the record auditors, insurers and customer security questionnaires ask for.

The printable version below has the full checklist and a blank sign-off sheet on A4.

Common things a first test turns up

• A system added after the backup was set up and never included.
• Backups that succeed but cannot be restored without a key or password only one person had.
• A restore that works but takes far longer than the RTO, usually because the copy is pulled over a slow internet link. The backup storage calculator estimates restore time from your bandwidth.
• The only off-site copy reachable with the same admin account as production, so ransomware could delete it too. See the UAE ransomware guide for how attacks get in.

None of these are rare, and all of them are cheaper to find on a quiet Tuesday than during an outage. Missan has 22+ years of running backup and recovery for UAE organisations, with 5,000+ clients served since 2004. If you would like a hand with the first one, ask for a backup review below.

Related Missan services

• Backup, disaster recovery and cloud
• FortGrid backup and DR (UAE)
• Backup storage and restore time calculator
• Managed IT services

Frequently asked questions

How do you test that a backup actually works?

Restore something from it to a separate location, open it, and check it is complete and current. For a server or database, restore it to an isolated network, start the services, log in and run a normal task such as a report. Time the whole process from "go" to "users could work". A green tick in the backup console only tells you a job finished.

How often should we run a restore test?

A small file or mailbox restore every month, a full restore of each critical system once a quarter, and a tabletop exercise of a full outage once a year. Rotate systems so that over a year every tier 1 system has had a full restore.

Do we need to back up Microsoft 365 if Microsoft already stores it?

Yes. Microsoft keeps the service running, but deleted items, ransomware that syncs into OneDrive and a compromised admin account are your problem. Retention policies and the recycle bin have time limits. Test that you can restore a mailbox, a SharePoint site and a OneDrive folder from your own backup.

Will a restore test disrupt users?

It should not. Restore to a different location, a test virtual machine or an isolated network, never over the live system. The only users involved are the one or two people from the business who check the restored data looks right.

Who should sign off a restore test?

The engineer who ran it records what was restored, how long it took and any problems. A system owner from the business confirms the data is usable. A manager, often the IT lead or the finance head, signs to accept the result or the fix plan. Auditors and insurers usually ask for this record.

What if the test misses our recovery time target?

Record it, do not round it. Then either fix the cause (slow storage, missing documentation, a restore that needs a person who has left) or agree a new target with the business. A missed target found in a test is cheap. The same miss during a real outage is not.

This guide is general information for planning, not legal or tax advice. Regulations and deadlines change; confirm the current position with the official source linked in the text and with your own advisers. Last reviewed 25/10/2026.