Every backup system faces its real test eventually — ransomware, a mass accidental deletion, a departing employee who wiped their OneDrive on the way out the door. Most small firms discover on that day that their backup didn't run as scheduled, returned corrupted files, or covered only part of what they assumed. The restore drill exists to find that out first.
The bottom line: A backup you have never restored is an untested assumption. Running a quarterly restore drill — attempting to recover actual files, not just confirming a backup job completed — is the only reliable way to know your data is recoverable. Microsoft 365 Business Premium does not include a full backup of Exchange, SharePoint, or OneDrive. A third-party backup solution is required to close that gap, and that solution must be tested on the same schedule as everything else.
What does Microsoft 365 actually protect?
Microsoft operates under a shared-responsibility model. Microsoft maintains the availability and integrity of its infrastructure. Your data — mailboxes, files, sites — is your responsibility. Microsoft 365 Business Premium includes versioning, recycle bin retention, and litigation hold options. These are useful features. They are not backups.
Specifically, they have limited retention windows that can be exhausted. Ransomware that overwrites file versions in place can consume that version history, leaving nothing to restore. And none of these features provide a point-in-time recovery of your entire tenant. A third-party backup tool that captures Exchange, SharePoint, and OneDrive data to an independent storage location is the correct solution for firms that need reliable recovery. If your IT provider has not had an explicit conversation with you about this, that conversation is overdue.
What a restore drill is — and what it is not
A restore drill is not a check on whether backup jobs completed. It is an attempt to recover actual data from your backup system as if a real incident had occurred. You select specific items — a folder of client documents, a user's mailbox, a SharePoint library — and attempt to restore them to a test location. Then you verify the restored data is intact and usable.
This matters because backup jobs can report success while restores fail. Encryption key mismatches, storage misconfiguration, software version conflicts, and permission errors all cause restores to fail in ways the completion log never flags.
The restore drill checklist
Work through each item in order. Record every result. Do not delegate this to a task that never gets verified.
- Identify what to test. Choose at minimum one file backup, one email mailbox or mailbox folder, and one SharePoint or OneDrive location. Cover the data types your firm actually depends on to operate.
- Choose a realistic scenario. Simulate accidental deletion by restoring a folder deleted several weeks ago. Or simulate ransomware by restoring files to a point-in-time before an assumed encryption event.
- Initiate the restore using your backup tool. Do not use a sync, export, or manual workaround. Use the actual restore function. Restore to a separate test folder — never to the live location.
- Verify the recovered data. Open files. Confirm they are the correct version, readable, and complete. For email, confirm message body and attachments are intact and in the right folder structure.
- Record the recovery time. Time the restore from initiation to usable data. Compare that number against your firm's real tolerance for downtime. If the answer is uncomfortable, your backup architecture needs review.
- Test across backup generations — not just the most recent. Ransomware commonly sits dormant before detonating. You may need to restore from a backup that is two or three weeks old. Confirm those older restore points work.
- Document every result. Record the date, items tested, who conducted the drill, recovery time, and any failures or anomalies. This log matters to regulators, cyber insurers, and — in a worst-case scenario — opposing counsel.