Recovery
Your backup succeeded—but can you get back to work?
A backup report cannot tell you how long staff would wait to resume work. A controlled recovery test can help answer that.
The backup report is green. The backup service reports that its job completed. It does not, by itself, show how long it would take to restore your application or whether staff could use it afterwards.
Recovery needs its own test. Can staff use the restored system, and can the business cope with the time it takes to get there?
Choose a task the business needs to resume
Start with a specific activity, such as retrieving a client file, processing an order or accessing the day's schedule. Identify the application, information, accounts and connections that make that task possible.
A restored database may still need a working application server, licences and a way for staff to sign in. Restoring only one piece can leave the business waiting.
The Cyber Centre's business continuity guidance connects recovery planning to critical operations, responsibilities and required timeframes. Use those business requirements to shape the technical test.
Agree on time and acceptable data loss
Ask management how long the activity can be unavailable and how much recent work could reasonably be recreated. These are two different limits.
Yesterday's backup could restore correctly and still leave the team re-entering a morning's orders. Whether that is acceptable depends on the records available, the people needed and the commitments made to customers.
Write down the assumptions. A recovery target is a planning requirement, not a promise that an untested arrangement will achieve it.
Run a controlled restore test
Have the responsible IT team agree on the scope, safeguards and success criteria. Use an isolated environment where appropriate so restored systems do not send live messages, process duplicate transactions or interfere with production.
The Canadian Centre for Cyber Security's ransomware playbook recommends regular testing of backups and restoration, alongside protecting backup copies against attack.
For the chosen task, check whether the restored information opens, the application behaves as expected and an authorized person can complete a representative piece of work. Record elapsed time, the recovery point used, missing dependencies and any manual steps.
Confirm who can authorize a restore, reach the provider and obtain required recovery credentials through an approved secure process. Consider what happens if ordinary email or the main sign-in system is unavailable.
Give a business representative responsibility for checking the result. A technician can confirm that a service starts; the person using it can confirm that the expected records and functions are available.
Report what the test demonstrated
Keep the result specific: which system and recovery point were tested, what worked, how long it took and what still needs attention. A successful file restore should not be reported as proof that the whole organization can recover.
Assign any gaps to an owner and arrange a retest when the corrective work is complete. Revisit the plan after significant changes to systems or business needs. Management can then compare the demonstrated recovery time with the interruption the business can tolerate.
Find out what your recovery plan can deliver
Discuss the systems you need to recover and how long you could manage without them. We can help plan a controlled restore test and address what it finds.