Infrastructure
The full domain, and the other capabilities within it.
Backup & Disaster Recovery
A backup you have not restored is an assumption.
What this is
This covers backup design, retention, immutability and offsite copies, together with the disaster recovery design that decides how a service comes back and how quickly. The two are separate: backup protects data, disaster recovery restores a service.
Almost every estate has backups. Far fewer have evidence of a restore under time pressure, and fewer still have backups an attacker cannot reach — which matters, because deleting or encrypting backups is now a standard step in a ransomware attack rather than an unusual one.
When you need it
If more than one of these is true, this is usually the right place to start.
- Backups running and reporting success, with no recent full restore test.
- Backup infrastructure reachable with the same credentials as production.
- Recovery objectives that were never stated, so nobody can say whether the current design meets them.
- A recovery plan written for a data-centre failure but not for encrypted production data.
What the scope covers
- Recovery objectives per service, agreed with the business rather than assumed by IT.
- Backup design: what, how often, retained how long, and where the copies live.
- Immutability and separation, so backups survive an attacker who holds production credentials.
- Disaster recovery design: failover, dependency order, and what degraded operation looks like.
- Restore testing on a schedule, with the results recorded and the failures fixed.
What you receive
| Deliverable | What it contains |
|---|---|
| Recovery objectives | RPO and RTO per service, signed off by the business, with the cost of each level made visible. |
| Backup design | Scope, schedule, retention, copy topology and immutability, mapped to the objectives above. |
| Recovery runbooks | Per scenario, in dependency order, written to be followed by someone who did not design the system. |
| Test results | Restore and failover tests with measured times against target, and remediation for anything that missed. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Measured restore time against RTO, from a real test rather than an estimate.
- Backup coverage against the service inventory, with exclusions listed rather than averaged.
- Time since the last successful full restore test per critical service.
Questions we are asked
What is the difference between RPO and RTO?
RPO is how much data you can afford to lose, which sets backup frequency. RTO is how long a service may be down, which sets the recovery design. They are separate decisions and cost different money; conflating them is why recovery plans miss.
Why does immutability matter?
Because ransomware now targets backups first. If backup storage can be deleted or encrypted with credentials the attacker already holds, it will be. Immutable copies cannot be altered for a defined window, which is what preserves the option to refuse to pay.
Is replication a backup?
No. Replication copies the current state, including corruption and encryption, usually within minutes. It protects against hardware and site failure. It does not protect against something bad happening to the data, which is what backup retention is for.
How often should we test restores?
Critical services at least annually end to end, and more often for anything that has changed. Partial tests — a file, a single machine — are useful but they do not prove a service comes back, because the difficulty is usually in dependency order.
Does cloud backup remove the need for this?
It changes where copies live, not whether the design is right. Cloud backup still needs retention, immutability, tested restores and an egress cost you have looked at before the day you need the data back quickly.
What about SaaS data?
It is the most common gap. Providers protect their platform; the retention of your data within it is usually limited, and deleted or maliciously altered content often falls outside it. SaaS data is treated as in scope unless a deliberate decision says otherwise.
Continue reading
Servers & Storage
Sizing, refresh and storage design driven by measured workload rather than by a vendor configurator — including what happens when a component fails.
Virtualization
Hypervisor cluster design, resource policy and right-sizing — including the licensing consequence of the design, which is where surprises usually arrive.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.