Ask What Has Actually Been Restored
The most useful backup question is simple: what have we restored recently? Not what could be restored. Not what the software says. What was actually restored, who did it, how long did it take, and what problems came up?
A restore test does not need to be reckless. It can be planned in a safe location with a sample server, a set of files, a mailbox, or a database. The goal is to learn before the emergency.
- When was the last restore test?
- Was it a file restore, mailbox restore, database restore, or full server restore?
- How long did recovery take?
- Were the steps documented afterward?
Separate Backup From Disaster Recovery
Backup is the copy. Disaster recovery is the plan for using that copy when the business is under pressure. The owner needs to know how much data can be lost, how long systems can be down, and which systems come back first.
A file server, accounting system, medical application, manufacturing workstation, and Microsoft 365 tenant may each need a different recovery approach. Treating them all the same usually leads to bad assumptions.
- Recovery time expectations for each important system
- Recovery point expectations for acceptable data loss
- Local backups, cloud backups, and offsite copies
- Ransomware isolation and protection from compromised admin accounts
Make the Plan Understandable
During a failure, people will not have time to decode vendor jargon. The recovery plan should say who to call, where credentials and documentation live, what systems matter first, and what decisions the owner may need to make.
If your provider cannot explain the recovery process in business terms, the plan is not finished.