Backup is not disaster recovery, and RPO and RTO set the price

One protects the data, the other protects the working day

Backup answers one question: can we get this file, this database, this mailbox back. Disaster recovery answers a different one: where does it run while we do that, in what order, and who decides the recovery has started. You can hold a flawless backup and still lose a week, because nothing in a backup tells you which machine the data comes back onto.

That gap is where most quotations sit. A backup line item buys copies. Disaster recovery buys somewhere to run, a documented order of recovery and a named person who owns the decision. The second costs more, largely because it involves capacity that sits idle until the day it earns its money.

A backup job reporting success proves the job ran

A green report says the software finished. It does not say the data is usable, and the gap between those two statements is where the failures live.

• A database captured mid-write because the snapshot writer failed and the job continued anyway
• A volume added to a server months ago that nobody added to the backup selection
• An encrypted archive whose only copy of the key lived on the server that died
• A repository on the same NAS the servers mount, so ransomware encrypted the backups too
• Retention that overwrote the last good copy before anyone noticed the corruption
• A job completing with warnings every night since the target disk filled in March

What a tested restore actually involves

Pulling one file out of a folder is not a test. Bring the system back onto a spare host or a virtual machine on an isolated VLAN, boot it, log in, open the application your staff actually use, and run a report whose answer you already know. Compare a row count or a closing balance against production.

Then write down how long the whole thing took, including the part where somebody had to find the licence key and the admin password. That figure is your real recovery time, and it is nearly always longer than the proposal's, because the proposal counted the data copy and not the forty minutes of hunting.

Restoring to different hardware is its own failure mode. A bare-metal restore onto a machine with a different storage controller can refuse to boot until the driver is injected, which is not the thing to discover at 2am. Virtual machines sidestep most of that, which is a real reason to consolidate onto a hypervisor before designing the recovery plan rather than after.

RPO and RTO are business decisions, and they set the price

RPO is how much work you are willing to re-enter. RTO is how long you can be shut. Both belong to whoever carries the cost of being down, not to the person configuring the backup software, and both are the reason two quotations for the same data can differ by a multiple.

A nightly job starting at 11pm gives an RPO of up to twenty-four hours. If the server fails at 4.30pm, a full day of billing entries, dispatch notes and cash receipts is gone and somebody re-keys them from paper, assuming the paper exists. For a factory dispatch desk or a hospital billing counter, that is the point at which hourly snapshots stop looking expensive.

RTO is arithmetic before it is anything else. Four terabytes across a gigabit link, at the seventy percent of line rate you realistically get, is close to thirteen hours of copying before anybody logs in. The same four terabytes pulled back from cloud storage over a 100 Mbps connection is closer to five days. If the stated RTO is four hours and the only copy is off-site, the plan is already wrong, and the arithmetic says so long before the incident does.

• Nightly backup to on-site disk plus an off-site copy: RPO up to twenty-four hours
• Hourly incrementals through the working day: RPO measured in the hour you lost
• Replication to a standby host in the same rack: RTO in minutes, at the cost of a second host
• Replication to a second building or to cloud: survives the building, and takes longer to pull back

Keep one copy your network cannot reach

Three copies, on two kinds of media, with one off-site remains the working rule. Add a fourth condition to it: one copy that nothing holding your admin password can delete. That means immutable storage, or a disk physically disconnected between runs.

Ransomware looks for the backup repository first, and a mapped drive with write permissions is the easiest target on the network. A backup that an attacker can encrypt from the same session that encrypted your file server has protected nothing.

Keep the runbook and the credentials somewhere outside the systems being recovered, on paper if necessary. A recovery plan stored only on the file server you are restoring is not a recovery plan.

What the plan has to state in writing

A recovery plan that lives in one engineer's head fails on the day that engineer is unreachable. These are the items that make it transferable.

• An RPO and an RTO per system, agreed by the person who owns the downtime
• The order systems come back in, because the ERP is useless without the domain controller
• Who declares a disaster, and who they call immediately after that
• Where credentials, licence keys and the runbook are held, off the systems being recovered
• The date of the last test restore and how long it took, start to finish
• The retention period, and therefore how far back a recovery can reach