Guide G14 Backup & disaster recovery
A backup job that runs is not the same as a recovery that works.
Most businesses can point to a backup schedule somewhere. Far fewer can say when a restore was last tested, how much data a real incident would cost them, or how long they could actually be down. This guide treats backup and disaster recovery as its own owned responsibility - separate from general managed IT and from day-to-day support - with the evidence worth demanding before anyone calls the problem solved.
G14 · Entry 01 Three different backup and recovery jobs
Start with what "backup" has actually been asked to prove.
This is a narrower question than the monitoring guide's "is anyone watching" - see the monitoring and RMM guide for whether a backup job is observed at all. This guide is about whether a restore from it has ever been proven to work.
Backups exist, but no restore has been tested
A schedule runs and a dashboard shows green. Nobody has actually restored a file, a mailbox, or a server from it in the last year.
Recovery time and recovery point need a real owner
Managed IT should name a recovery point objective - how much data you could lose - and a recovery time objective for the systems that matter most, instead of leaving both assumed.
A close call already happened
A near-miss outage or ransomware scare is a reasonable trigger for a bounded review of coverage and single points of failure - not a reason to panic-buy a tool.
G14 · Entry 02 Decision matrix
Match the situation to the right first route.
| Observed need | Best first route | Useful evidence | Boundary |
|---|---|---|---|
| Backups run, but no restore has ever been proven | Managed IT or a bounded review | Last test-restore date and result | Not a guarantee against every future failure |
| No one can state RPO/RTO for critical systems | Managed IT | Named recovery point/time targets, current backup scope | Not a legal or insurance requirement by itself |
| One vendor, location, or person is a single point of failure | Managed IT or advisory | Current backup topology, dependency map | Not an instant fix for a one-person IT setup |
| An outage or ransomware event is happening now | Existing incident, insurer, or legal process first | Incident timeline, affected systems, isolation already done | A directory does not perform incident response |
G14 · Entry 03 Prepare the brief
Bring these facts to a backup and recovery conversation.
- What is backed up today, and what is explicitly not covered.
- The last time a real restore was tested, and what happened.
- Any stated or assumed recovery point and recovery time for critical systems.
- Where backups are stored, and whether one vendor or location is a dependency.
- Who is responsible for checking backup success day to day.
- Whether a written recovery order exists for critical systems - what comes back first.
G14 · Entry 04 What this covers
What this guide covers, and what it does not.
- In scope
- Naming the tested-restore, RPO/RTO, and single-point-of-failure evidence a backup and disaster-recovery conversation should produce.
- Out of scope
- Performing backups, executing a live recovery, or replacing cyber-insurance or incident-response obligations.
- Possible next decision
- Ongoing backup and recovery ownership under managed IT, or a bounded recovery-readiness review under advisory.
G14 Next
Ask for a tested restore, not a green dashboard.
Compare ongoing ownership routes for recurring recovery testing, or read the advisory guide if what you need first is a bounded readiness review.