Almost every backup dashboard shows green checkmarks. Unfortunately, a green checkmark means the job ran, not that the data can be restored, that it is complete, or that you can get it back fast enough. The only way to know is to restore something and see what happens. For a law firm with court deadlines and client confidences, finding a problem during a test is far better than finding it during a ransomware incident.
This guide describes a restore testing routine that a firm can run on a regular schedule.
Why testing matters
Backup failures are often silent. Common causes include expired credentials, full storage, exclusions that omit an important folder, corrupted backup chains, and changes to the environment since the backup was configured. Testing also reveals the human factors: whether anyone knows the procedure, where the passwords are, and how long recovery really takes.
Decide what you are measuring
Two targets guide the test:
- Recovery point objective (RPO): how much recent work the firm could lose. If backups run nightly, you could lose up to a day.
- Recovery time objective (RTO): how long the firm can function without a given system.
Write down the targets for each critical system, then measure whether the test meets them.
A tiered testing schedule
Monthly: file-level restore
Pick a few random files from different matters, including some from several weeks ago, and restore them to an alternate location. Open them and confirm they are intact. Record how long it took.
Quarterly: application-level restore
- Restore a full mailbox, or a deleted folder, from your Microsoft 365 backup.
- Restore a document-management or practice-management export if you maintain one.
- Restore a database used by billing or accounting software, if you host one locally.
Verify that the application can actually use the data. A restored database file that will not open is not a successful test.
Annually: full recovery exercise
Simulate a major failure. Restore a server, or a whole set of systems, into an isolated environment or onto spare hardware or cloud capacity. Time it from the moment you decide to recover until users could work. Include the steps that happen around the restore: rebuilding user access, reconnecting printers and applications, and communicating with staff.
A step-by-step test procedure
- Choose scope and date. Pick the system and a time that will not disrupt work.
- Assign roles. One person performs the restore, another documents, and a partner or administrator observes.
- Use the documentation only. If the restorer needs to rely on memory or ask the one person who knows, the runbook has a gap.
- Restore to a safe location. Never overwrite live data during a test.
- Validate. Check file integrity, open documents, run application checks and compare file counts or sizes where possible.
- Record the result. Note start and end times, problems and fixes.
- Fix and retest. Address each failure and retest the specific item.
Include the ransomware scenario
Test restoring from the immutable or offline copy, not just the convenient local one. Confirm that the account used to access that copy is separate from your main administrator credentials and has multi-factor authentication. Consider a scenario in which your domain is compromised. Can you still log in to the backup console? CISA's ransomware guidance emphasizes maintaining offline, encrypted backups and testing availability and integrity regularly.
Check what is missing
Compare your backup scope to your inventory:
- Laptops and desktops with locally saved files
- Cloud platforms such as practice-management and document systems
- Microsoft 365 data, including Teams and SharePoint
- Phone systems, firewall configurations and other network devices
- Encryption keys and password vaults
- Databases for accounting, time and billing
Anything not covered is a risk you have accepted without deciding to.
Common problems found during tests
- Backups exist but the encryption key or password cannot be found
- Restore takes days, not hours, because of bandwidth limits
- Permissions on restored files are wrong
- A critical share was never included in the backup job
- Only one person knows how to run the recovery
Keep a recovery runbook
Maintain a short document that lists systems in priority order, contact numbers for vendors, backup locations, who is authorized to start recovery and how to reach the backup console if the network is down. Store a copy offline and with an off-site contact. During an incident, nobody wants to search for it.
Share results
Report test outcomes to the partners, including any gaps and the budget needed to close them. Cyber-insurance applications and client questionnaires frequently ask whether backups are tested and when, so keep the reports on file.
Counsel Cyber builds and runs restore testing programs for law firms, including full-recovery drills with documented results. If you have not tested recently, we would be glad to help you run your first one.