The most surprising thing about database backup storage is that the "best" location isn’t always the most convenient or the cheapest; it’s the one that guarantees you can restore when your primary infrastructure is compromised.
Imagine you’re running a critical application, and your database is the heart of it all. You’ve diligently set up backups, but where are they going? Let’s say you’re using AWS RDS. You’ve got your database instance, and you’ve configured automated backups. By default, RDS stores these backups on Amazon S3, but crucially, it’s within the same AWS region as your database instance.
Here’s a quick peek at what that looks like in practice. When you set up an RDS instance, you can see the backup retention period. Let’s say it’s set to 7 days.
{
"DBInstanceIdentifier": "my-prod-db",
"BackupRetentionPeriod": 7,
"BackupWindow": "03:00-04:00",
"BackupLocalSnapshotIdentifier": "arn:aws:rds:us-east-1:123456789012:snapshot:rds:my-prod-db-2023-10-27-03-00",
"BackupDestination": "S3"
}
This BackupDestination being "S3" is key. RDS handles the S3 interaction for you, but it’s S3 within your current region. If you’re using a different cloud provider or on-premises, the principle is the same: your backup storage needs to be accessible and ideally geographically distinct.
So, what problem does this solve? Disaster recovery. If a region-wide outage hits your primary cloud provider (think a major hurricane, a massive power grid failure, or even a catastrophic configuration error that wipes out your entire VPC), your database instance is gone. If your backups are also in that same region on S3, they are likely gone too. You’re left with nothing.
The mental model here is about redundancy. You need at least two copies of your data: the live database and the backup. And for true resilience, those copies need to be in different failure domains. A failure domain can be a single server, a rack, an availability zone, or an entire region. For robust disaster recovery, you’re aiming for cross-region or cross-cloud redundancy.
To achieve this, you’d typically configure your backup system to copy backups to a separate region. For RDS, this is often done via cross-region snapshot copying. You can manually initiate a copy of an automated backup snapshot to another region.
Let’s say you want to copy a snapshot to us-west-2. You’d use the AWS CLI:
aws rds copy-db-snapshot \
--source-db-snapshot-identifier arn:aws:rds:us-east-1:123456789012:snapshot:rds:my-prod-db-2023-10-27-03-00 \
--target-region us-west-2 \
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id \
--tags Key=Purpose,Value=DRBackup
This command takes the snapshot (source-db-snapshot-identifier) from us-east-1 and copies it to us-west-2. The --kms-key-id is important if your source snapshot is encrypted; you’ll need a KMS key in the target region.
The choice of volume type for direct backup storage (if not using a managed service like RDS with S3) also matters. If you’re backing up directly to EBS volumes attached to EC2 instances, you’d want to consider io2 Block Express volumes for high-performance, durable storage, especially for large databases. These offer the highest IOPS and throughput, ensuring your backups complete quickly without impacting the production database. However, even these are typically tied to a specific Availability Zone. The cross-region copy to S3 remains the primary DR strategy.
The one thing most people don’t realize is that even if you’re backing up to S3 in a different region, you still need to ensure your restore process is tested and functional in that target region. Having a backup in us-west-2 is useless if you can’t spin up a database instance there and attach it to your application, which might also need to be redeployed to us-west-2.
The next step is understanding how to orchestrate a full disaster recovery plan, including application failover.