A recovery plan that has never been executed is a document, not a capability. The test is the deliverable.
Recovery Time Objective is how long you can be down. Recovery Point Objective is how much data you can afford to lose. Both are business decisions with a direct cost, and they differ enormously between systems.
A blanket organisational target is either far too expensive for most systems or far too weak for the critical few. Set them workload by workload and have the business own the numbers.
Paying for active-active on a system whose users would tolerate four hours of downtime is a common and avoidable expense.
Backups fail quietly. Retention is misconfigured, a database is excluded, encryption keys are unavailable at restore time, or the backup completes but is not consistent.
Schedule restore tests and treat a failed restore as a production incident. Until a backup has been restored into a working system, it is an assumption.
Recovery involves DNS, certificates, secrets, dependencies on third parties and people knowing what to do at an inconvenient hour. Only a rehearsal exposes those.
Run one at a planned time, document what went wrong, fix it, and repeat periodically. Organisations that rehearse recover; organisations with a plan document usually discover its gaps during the incident.
Recovery plans concentrate on application and data, and incidents are frequently prolonged by something else entirely: an expired certificate nobody could reissue, a DNS record only one person could change, or a third-party service that also needed reconfiguring.
List the dependencies outside your own infrastructure — domain registrar, certificate authority, identity provider, payment processor, monitoring — and confirm who can act on each, out of hours.
Access to the recovery documentation is itself a dependency. A runbook stored only in the system that is down has failed at exactly the moment it was needed.
At least annually for most systems, and quarterly for anything whose failure would materially disrupt the business. Test after significant architectural change as well.
Only where the recovery objective demands it. Multi-availability-zone deployment within one region handles the most common failure modes at a fraction of the cost and complexity.
No. Managed services protect against infrastructure failure, not against deletion, corruption or a bad deployment. You still need point-in-time recovery you control.
Keep reading
The overspend is rarely caused by the cloud itself. It is usually set in motion by three decisions taken in the first few weeks, often by people who did not realise they were making them.
All four run the same workloads competently. The decision usually follows existing commitments, data residency and the skills already in your team.
A meaningful share of cloud spend on a typical estate is recoverable without changing the architecture at all. Start there.
