Disaster Recovery and Backup Strategies

At its simplest, disaster recovery (often shortened to DR) is a set of actions you take to get your IT systems running again after a disaster. A disaster is any event that stops your normal operations – a power outage in the data centre, a fire, a ransomware attack that locks your files, or even a software bug that corrupts a database. A backup, by contrast, is just a copy of your data. You can have a backup without a DR plan, but that is like having a spare tyre in your boot without knowing how to change a wheel.

To understand DR and backup in AWS, you must first grasp a few fundamental ideas. The first is the Recovery Point Objective, or RPO. Imagine you have a backup of your files taken every 24 hours. If a disaster happens at 11pm, you have lost all changes made since the last backup at midnight. The RPO is that 23-hour window of potential data loss. It is the maximum age of the data you are willing to lose. The second is the Recovery Time Objective, or RTO. This is the maximum amount of downtime you can tolerate. If you say your RTO is 4 hours, you need to get your systems fully working again within 4 hours of the disaster starting.

AWS offers several distinct DR strategies, each with different RPO and RTO characteristics. They are often explained using the 'backup and restore' model, the 'pilot light' model, the 'warm standby' model, and the 'multi-site active-active' model. Let us break each down.

Backup and Restore is the simplest and cheapest. You periodically copy your data to an AWS storage service like Amazon S3 (Simple Storage Service). If a disaster occurs, you restore from that backup into a new environment. This has the worst RPO and RTO – you could lose up to a day's worth of data, and restoring a large application could take hours or days. It is like recovering your phone from a last-week backup: you get most things back, but you lose your new contacts and photos.

Pilot Light is cheaper than a full replica. You keep a minimal copy of your core data and critical infrastructure running in another AWS region (a separate geographical location). You do not run the full application there – just the database replication and a few tiny servers (often the smallest EC2 instance type) to keep the data synchronised. When a disaster hits your main region, you 'turn on' the rest of your application infrastructure around that core data. This provides a faster recovery than backup and restore because the database is already current, but you still have to provision and start the application servers.

Warm Standby goes a step further. You run a scaled-down but fully functional version of your entire application in the second region. It handles low traffic or just stays ready. If a disaster strikes the primary region, you scale up this standby environment to full size and redirect traffic to it. The RTO is much shorter – maybe minutes to an hour – because the infrastructure is already there. The cost is higher because you pay for those running resources even when they are idle.

Multi-Site Active-Active is the most expensive and most resilient. You run your full application in multiple regions simultaneously, with traffic being distributed across them using services like Amazon Route 53 (AWS's Domain Name System service) or a global load balancer. If one region fails, the remaining region continues serving traffic without interruption. RPO is often seconds, and RTO can be near zero – but the cost is double (or more) because you are paying for full infrastructure in two places.

Underpinning all these strategies is the concept of replication. AWS offers different ways to copy data between regions. Amazon S3 supports Cross-Region Replication (CRR), where every object uploaded to one bucket is automatically copied to a bucket in another region. Amazon RDS (Relational Database Service) offers Multi-AZ (Availability Zone) deployments for high availability within a region and Cross-Region Read Replicas for DR across regions. AWS also provides a service called AWS Backup, which allows you to centralise and automate backups across multiple AWS services, setting retention policies and creating backup plans from a single console.

Another important concept is the difference between an Availability Zone (AZ) and a Region. An Availability Zone is a single data centre or a small cluster of data centres within a region. A Region is a large geographic area (like US East or Europe West) containing multiple AZs. For DR across regions, you are talking about recovering in a completely different geographic location, which protects against region-wide disasters (like a major earthquake or a power grid failure affecting a whole area). For high availability (HA) within a region, you spread resources across multiple AZs to protect against a single data centre failure.

Finally, you need to understand the concept of data durability and availability. Data durability refers to the likelihood of not losing an object – Amazon S3 Standard storage offers 99.999999999% durability, meaning if you store 10 million objects, you expect to lose one object every 10,000 years on average. Availability is how often you can access your data – S3 Standard offers 99.99% availability, meaning it may be inaccessible for about 53 minutes per year. For DR, you want both high durability and high availability, but you may trade off cost for speed of recovery.

Imagine you work for a medium-sized e-commerce company that sells handmade furniture online. The company's application runs entirely in AWS us-east-1 (North Virginia). Your database is an Amazon RDS PostgreSQL instance, your application runs on Amazon EC2 instances behind a load balancer, and all product images are stored in an Amazon S3 bucket. Your boss comes to you and says, 'We cannot afford a full second region, but we absolutely cannot lose more than 15 minutes of orders. And if the whole us-east-1 region goes down, we need to be selling again within one hour.'

Your job is to design a disaster recovery solution that meets these constraints. You start by evaluating the RPO: 15 minutes of data loss. This rules out backup and restore for the database because restoring from a daily backup would lose hours of orders. You also rule out Multi-Site Active-Active because the cost of running a full application in another region is too high. This leaves Pilot Light or Warm Standby as the viable options.

Let us walk through the Warm Standby implementation step by step. You decide to use us-west-2 (Oregon) as your DR region.

First, you set up cross-region replication for the S3 bucket containing product images. In the AWS Management Console, you enable Cross-Region Replication (CRR) on the source bucket in us-east-1, specifying a destination bucket in us-west-2. You also configure AWS Backup to take daily snapshots of the database and store them in a backup vault in us-west-2.

Second, for the database, you create a cross-region read replica of your RDS instance in us-west-2. This replica is read-only and is constantly synchronised with the primary database. The data lag is typically a few seconds, which safely meets your 15-minute RPO. You keep this replica running on a small instance class to minimise cost.

Third, you build a scaled-down version of your application in us-west-2. You launch a few EC2 instances (say, two t3.micro instances) behind an Application Load Balancer in that region. You also create a small Aurora read replica for any read-heavy queries if needed, but the main data synchronisation is through the RDS read replica. You do not direct any customers to this environment during normal operations – it just exists, powered on and ready.

Fourth, you automate the failover process. You write an AWS Lambda function that is triggered by a CloudWatch alarm (for example, if the health check to your primary application endpoint fails for 5 consecutive minutes). The Lambda function performs several actions in sequence: it promotes the read replica in us-west-2 to become a standalone, writable database; it then launches more EC2 instances in us-west-2 and registers them with the load balancer; it also changes a Route 53 DNS record (using a failover routing policy) to point the company's domain (shop.example.com) to the Application Load Balancer in us-west-2. You also trigger the restoration of the latest S3 backup if needed, though with CRR enabled, the images should already be there.

Finally, you test the failover. Every quarter, you schedule a 'game day' where you deliberately stop the primary database and trigger the Lambda function manually. You and your team watch the clock to confirm the application is serving requests from us-west-2 within the one-hour RTO. You also measure the data loss by comparing the last order timestamp before the failover with the timestamp of the last record in the promoted database. You document every step, identify any bottlenecks, and update the automation to improve the RTO over time.

In summary, the real-world work involves choosing the right AWS services (RDS read replicas, S3 CRR, Route 53, Lambda, CloudWatch), configuring them correctly, automating the recovery process, and then testing it repeatedly to ensure it works when a real disaster hits.