← Writing

Backup or disaster recovery? Start with downtime.

Before choosing a product, decide how much time and data the business can afford to lose.

Recovery, drawn simplyData protection
LAST USABLE COPYINCIDENTBACK IN SERVICERPORTOHow much data can you lose?How long can you wait?
Two different gaps. Two different promises.

A backup can have a lovely green tick and still leave you offline for a day. A standby system can start in minutes and still contain the problem you hoped to escape. Start with the outage you need to survive, then choose the tools.

Start with two questions

How much recent work could you lose? The recovery point objective, or RPO, describes the maximum acceptable gap between the last usable recovery point and the incident. If losing a day of changes is unacceptable, a nightly backup alone will not meet that objective.

How long could you wait to work again? The recovery time objective, or RTO, describes how quickly the service needs to be restored. A recent copy of the data does not by itself guarantee a quick return to operation.

What backup is good at

Backups give you recovery points and a way to retrieve data after deletion, corruption or a larger failure. They can support longer retention and let you go back to an earlier state. The time it takes to recover depends on the amount of data, the available infrastructure, transfer speed and the steps needed to make the restored system usable.

A dashboard saying “successful” tells you the job ran. It does not tell you whether the data opens after a restore. Test that part.

What disaster recovery adds

A disaster recovery design aims to resume an application or environment quickly, often by preparing a secondary place where it can run. That can shorten downtime, but it does not remove the need for backups or longer retention. Replication can copy a problem too; it is not a magic undo button.

The right design may include both: backups for dependable recovery points and retention, plus a faster failover path for workloads whose downtime would be especially costly.

Make the decision with the business

Start with the people whose work would stop. Ask what the outage would cost them and which data changes they could not recreate. Turn those answers into RPO and RTO targets for each important workload, then check whether the proposed design can meet them under realistic conditions.

Finally, test the recovery. The plan becomes useful when the people responsible know the steps, have run them, and can explain the result.

Have a recovery question worth working through?

Get in touch