A backup report that says "completed successfully" tells you the software wrote some data. It does not tell you that the data is complete, readable, current or restorable in the time your firm can tolerate. The only way to know is to restore something and see what happens.
Many firms avoid restore testing because it sounds disruptive or risky. It does not need to be. Done properly, it takes a few hours each quarter and never touches production data.
Why Testing Matters
Backups fail quietly for many reasons: a folder was never added to the job, credentials expired, storage filled up, a software update changed behavior, or a file was corrupt before it was copied. These problems are invisible until the day you need the data. Finding them during a calm Tuesday test is dramatically cheaper than finding them during a ransomware incident.
Three Levels of Testing
Level 1: File-level restore
Pick a few real matter folders and individual documents, and restore them to a separate location. Open them. Confirm that recent changes are there and that nothing is missing. This is quick and should happen at least monthly.
Level 2: System-level restore
Restore a full server or virtual machine to an isolated environment, which a provider can do without connecting it to your live network. Confirm that it boots, that services start and that data is intact. Do this at least quarterly or after major changes.
Level 3: Full disaster recovery exercise
Simulate the loss of your primary location or environment and bring critical systems up from backup. Measure how long it takes. Many small firms do this annually, often with a partner or provider running the exercise.
What to Test
- Document management and file shares. Restore a matter folder with a variety of file types.
- Email. Recover a deleted mailbox item and a full mailbox, if your backup covers it.
- Practice-management and billing data. Confirm you can recover or export your records.
- Databases and line-of-business applications. These often need special handling to restore consistently.
- Configuration. Firewall, domain controller and cloud settings are easy to forget and slow to rebuild from memory.
A Simple Test Procedure
- Choose the scope and date, and notify the people involved.
- Select items at random rather than the same easy folder each time.
- Restore to an isolated location, never over live data.
- Verify contents: open files, check dates, run a few searches.
- Record the time it took from request to usable data.
- Compare the result to your recovery time and recovery point objectives.
- Document any failures, fix them and retest.
What to Record
Keep a short log with the date, who ran the test, what was restored, how long it took, whether it passed and what was fixed. This record is useful in several ways. It shows partners that the investment is working, supports answers on cyber-insurance applications and client security questionnaires, and gives evidence of reasonable care consistent with Model Rule 1.6(c)'s focus on reasonable safeguards.
Common Problems Testing Reveals
- Data that was never included in the backup scope.
- Restores that take far longer than anyone assumed.
- Missing encryption keys or passwords needed to open the backup.
- Backups of encrypted laptops that cannot be read without the recovery key.
- Applications that restore but will not run without a specific configuration.
Each of these is easier to solve now than in a crisis.
Set Realistic Expectations
If your restore test shows that bringing everything back would take three days and your firm can tolerate one, that is valuable information. You can then decide whether to invest in faster recovery methods, prioritize critical systems or adjust expectations with clients.
How Counsel Cyber Supports Testing
Counsel Cyber runs scheduled restore tests for law firms and delivers a plain-English report you can share with partners, insurers or clients. If you are not sure when your last successful restore happened, we can help you find out.