Backup, Restore, and Point-in-Time Recovery Strategies

Database backup is the process of creating a copy of your database so you can restore it later if the original is lost or corrupted. AWS offers several ways to do this. The simplest is automated backups. When you enable automated backups on Amazon RDS or Amazon Aurora, the service automatically creates a daily snapshot of your entire database instance and also uploads transaction logs to Amazon S3. These logs record every single change made to the database — every INSERT, UPDATE, or DELETE statement. With these logs, you can perform point-in-time recovery (PITR), which lets you restore your database to any second within the backup retention period (typically between 1 and 35 days). This replaces older manual approaches where you had to schedule and store full backups yourself and could only restore to the moment of the last backup, losing any changes made between backups.

Another key concept is the database snapshot. A snapshot is a static, point-in-time copy of your whole database instance. Unlike automated backups, snapshots are user-initiated and persist until you delete them. They also include the entire storage volume, not just the database engine data. Snapshots are stored in Amazon S3, but you only pay for the storage they use. For Amazon RDS, automated backups are automatically deleted when you delete the database instance, but manual snapshots remain even after the instance is deleted. This is critical for exam questions about retention and compliance.

Cross-region backups are essential for disaster recovery. If an entire AWS region (like us-east-1) goes down, you lose all resources in that region. By copying automated backups or snapshots to a different AWS region, you ensure that even a full region outage cannot destroy your data. AWS RDS can automatically copy automated backups to another region if you configure cross-region backup. DynamoDB has global tables that replicate data across regions in near real time. Aurora offers cross-region read replicas and also cross-region snapshot copy.

For exam purposes, you need to understand the default settings. RDS automated backups are enabled by default with a retention period of 7 days. Snapshots are not automatic. PITR requires automated backups to be enabled. The retention period can be increased up to 35 days, but this costs more because you store more transaction logs. If you disable automated backups, you lose PITR capability entirely. Aurora has a special feature called backtrack, which allows you to rewind the database to a specific time without needing to restore from a snapshot, but it uses a different mechanism than standard PITR.

DynamoDB has on-demand backup and point-in-time recovery. On-demand backups are full snapshots you trigger manually. PITR for DynamoDB lets you restore your table to any point in time within the last 35 days. When you enable PITR on a DynamoDB table, AWS continuously records changes, so you can go back to any second. This is incredibly powerful because it means you can recover from accidental writes or deletes without having to restore an entire snapshot and replay logs.

Restoring from a backup creates a new database instance. You cannot overwrite an existing instance with a restored backup — you always get a fresh instance. This is important: restore creates a new DB instance with a new endpoint. You then need to update your application to point to the new instance, or use DNS tricks to swap the endpoint. This is called a restore operation.

Imagine you are the database administrator for an e-commerce platform that processes 10,000 orders per hour. The company has a compliance requirement to keep seven years of order data, but also must be able to recover from any data loss within 15 minutes. You design the backup strategy as follows.

First, you enable automated backups on the production Amazon RDS for PostgreSQL instance with a retention period of 35 days. This gives you PITR capability for the last 35 days. Every day at 2:00 AM, AWS takes a snapshot. Transaction logs are uploaded every five minutes. If a developer accidentally runs a DELETE without a WHERE clause at 3:47 PM on Tuesday, you can restore the database to exactly 3:46:59 PM Tuesday, losing at most five minutes of data.

Second, you create a manual snapshot once per week and copy it to a different AWS region (us-west-2). You also copy the automated backup to another region. If the primary region (us-east-1) experiences a natural disaster and is completely unavailable, you can restore that cross-region snapshot in the secondary region and point your users there. You test this recovery process quarterly.

Third, you enable deletion protection on the database instance. This prevents anyone from accidentally deleting the production database. Even if an administrator tries to delete it, the operation fails unless deletion protection is turned off first. This is a simple but crucial safety net.

Fourth, you set up AWS Backup — a centralised backup service that automates backup policies across multiple AWS services. You create a backup plan that says: 'take a daily backup, retain for 35 days, copy to us-west-2, and notify the ops team if a backup fails.' AWS Backup manages the lifecycle, retention, and cross-region copying automatically.

One day, the worst happens: a ransomware attack encrypts the production database. You immediately stop all application traffic, then use the AWS Management Console to restore the most recent automated backup to a new RDS instance. Since PITR is enabled, you restore to the point in time just before the attack started — say 11:45 AM, when the last clean transaction log was written. The new instance is up and serving data within 10 minutes. You then remove the infected instance and update your application’s connection string to point to the new clean instance. The company loses less than 15 minutes of data, meeting the recovery point objective (RPO) of 15 minutes. The recovery time objective (RTO) is also met because the restore completed within the required time.