Recovery Strategies
Backup approaches, failover options, and the cost of getting it wrong.
Overview
A recovery strategy that has not been validated against your actual RTO/RPO requirements, tested under realistic conditions, and costed accurately is an assumption, not a plan. Answer the five questions below with the technical and financial specificity that recovery architecture decisions require.
Read before you answer
Recovery strategy selection is the process of choosing the technical and operational approaches that will enable an organisation to meet the RTOs and RPOs established in the BIA. The strategy must be matched to the objective: a 15-minute RTO requires a fundamentally different architecture than a 24-hour RTO, and the cost difference is significant. The spectrum of IT recovery strategies runs from cold standby (a spare environment that must be provisioned and configured from scratch when needed β the cheapest option, with the longest recovery time), through warm standby (a pre-provisioned environment that requires data restoration and some configuration before it is operational β intermediate cost and recovery time), to hot standby (a fully operational mirror environment that can accept traffic immediately, typically via automated failover β the most expensive option, with the shortest recovery time). Cloud infrastructure has substantially changed the economics of warm and hot standby approaches by eliminating the need to own and maintain physical secondary hardware.
Backup strategy is the foundation of any recovery architecture. The 3-2-1 rule is the baseline: three copies of data, on two different media types, with one copy off-site. In modern cloud environments, the "off-site" requirement is typically met by replicating to a different cloud region or availability zone. Key backup parameters include: backup frequency (how often backups are taken, which directly determines RPO); retention period (how long backups are kept, which determines how far back you can restore); backup type (full, incremental, or differential, with trade-offs between backup duration and restore duration); and backup verification (whether backups are actually tested for restore integrity β untested backups are a common source of recovery failures). Encryption of backup data at rest and in transit is a security baseline; backup access controls are a governance requirement that is frequently overlooked until a ransomware incident demonstrates that attackers specifically target backup systems to prevent recovery.
Cloud-based recovery strategies introduce both new options and new considerations. Cloud-native DR services (AWS Elastic Disaster Recovery, Azure Site Recovery, Google Cloud's backup and DR services) enable replication of on-premises workloads to cloud environments with configurable RPOs measured in minutes. Containers and infrastructure-as-code enable recovery from configuration as well as data, reducing the dependence on backup for the infrastructure layer. The key considerations for cloud DR are: network connectivity (if the WAN link to cloud is unavailable during a disruption, cloud DR may not be accessible), data sovereignty (regulatory requirements may restrict where backup data can be stored geographically), cost management (cloud DR costs increase with data volume and replication frequency β they must be modelled, not assumed), and testing (cloud DR environments are particularly easy to spin up and test regularly, and there is no excuse for untested cloud DR architecture).