Most companies can tell you that their backups run every night. Far fewer can tell you how long it would take to restore the accounting system, whether the restored data would actually open, or who would perform the work if the usual administrator were on vacation. Those are the questions a ransomware attack or server failure forces you to answer, usually at the worst possible time.
A restore test is the only way to learn the answers ahead of time. It need not be elaborate. Here is a practical approach for a business without a large IT department.
What a restore test is, and is not
A successful backup job report tells you that data was copied. A restore test tells you that the data can be brought back, in a usable state, within a time you can live with. The first is a log entry. The second is a capability.
Step 1: Choose what to test
Pick systems in order of business impact. A good first list for a contractor might include:
- The accounting and payroll database
- The file server or SharePoint library that holds project documents
- A user mailbox
- An entire server or virtual machine
- Configuration files for firewalls and network equipment
Energy companies should add controller programs and historian data when those are in scope for backups.
Step 2: Set success criteria beforehand
Decide what passing looks like before you start. For each system, write down:
- The maximum acceptable time to restore
- The acceptable data loss, meaning how recent the restored data should be
- How you will check that the restored data is complete and correct
For example, a controller or payroll clerk should open the restored accounting file and confirm that the last closed period and recent transactions are present.
Step 3: Restore to a safe place
Never restore over production data during a test. Restore to an isolated location or a test machine, with no connection to your live network if the restored system could conflict with the original. Many backup tools support restoring to an alternate location for this purpose.
Step 4: Time every step
Start a stopwatch. Record how long it takes to locate the right backup, start the restore, wait for the data transfer, and complete configuration. Honest timing is the most valuable output of the exercise, because it often reveals that recovery takes days where leadership assumed hours.
Step 5: Verify the data
Have a business user, not only an IT person, check the results. Open files, search for recent records, run a report. Confirm that permissions and application functions work. A restored database that will not open is a failure even if the copy completed.
Step 6: Include the unglamorous scenarios
Once the basics work, try harder cases:
- Restore from the oldest retained backup, to confirm that retention is real
- Restore a single deleted file from a user's folder
- Restore when the primary administrator account is unavailable
- Restore without access to the usual office network, as if the building were unusable
- Restore an application along with its supporting server, not just the data
Step 7: Document and fix
Create a one-page record for each test with the date, the system, who performed it, how long it took, whether it passed and what went wrong. Convert problems into action items with owners and due dates. Typical findings include missing encryption keys, outdated documentation, backups that skip a folder and slow internet links that stretch the timeline.
How often to test
- Critical systems: at least quarterly
- Other important systems: twice a year
- Whole-environment recovery rehearsal: at least once a year if feasible
- After major changes, such as a new server, migration or backup product
Protect the keys and credentials
Encrypted backups are useless if the encryption key is lost or stored only on the system that failed. Keep backup credentials and keys in a secure place that you can reach during an outage, such as an offline copy held by a trusted executive.
Share the results with leadership
Present the findings in business terms: "Our payroll system could be restored in about X hours" is more useful than technical detail. If the answer is unacceptable, leaders can decide to invest in faster recovery methods.
How Ironfield Cyber helps
Ironfield Cyber runs scheduled restore tests for managed clients and reports the results in plain language. If you have never tested your recovery, we can help you plan a first test that is safe and informative.