Comparison
Disaster recoveryvsRecovery time objective
Disaster recovery
the plan for the day a whole region, account or dataset is gone, written down and hopefully rehearsed once a year.
The prepared response to losing an entire environment — a region, an account, a dataset — as opposed to the ordinary failures your architecture absorbs. It is defined by two numbers, how much time and how much data you can lose, and everything else follows from them. Its recurring failure is that the plan exists and has never been executed, so nobody knows that the restore takes eleven hours or that the credentials to run it are in the environment that is gone.
Full entry →Recovery time objective
the business says four hours, and the restore has never been timed, so nobody knows whether that is true.
The maximum acceptable time to restore service after a disaster: how long you may be down. It is a business decision that dictates architecture, because an hour and a day buy completely different designs. The only honest way to hold it is to measure a real restore, since an untimed objective is a number in a document rather than a property of the system.
Full entry →