RDS Backups & Snapshots

Amazon RDS (Relational Database Service, AWS’s managed SQL database) gives you two ways to protect your data: automated backups and manual snapshots. Both create copies of your database, but they behave very differently when it comes to retention, recovery, and cost. Getting this right is the difference between losing an hour of data and losing everything, so it is worth understanding clearly before you go to production.

Automated backups and point-in-time recovery

When you enable automated backups, RDS does two things every day. First, it takes a full daily snapshot of your database during a backup window you choose. Second, it continuously uploads your database’s transaction logs (a running record of every change) to Amazon S3 (AWS’s object storage) every 5 minutes.

Combining the daily snapshot with the transaction logs lets you do point-in-time recovery (PITR) — you can restore your database to any second within your retention window, not just to the moment a snapshot was taken. For example, if a bad migration deleted a table at 14:32, you can restore to 14:31.

The retention period controls how far back you can go. It can be set from 1 to 35 days. A value of 0 disables automated backups entirely (not recommended for production).

Gotcha: PITR only covers the retention window. If your retention is 7 days, you cannot restore to a state from 10 days ago. For long-term archival (compliance, year-end records), you need manual snapshots, which never expire on their own.

When to use this

Automated backups are for operational recovery — undoing accidental deletes, recovering from a bad deploy, or rolling back a corrupted state in the recent past. Keep them enabled on every production database. They are not a good fit for long-term archival because of the 35-day cap.

Setting the retention period

Console steps:

1. Open the RDS console and choose Databases in the left menu.
2. Select your database instance, then click Modify.
3. Scroll to Backup and set Backup retention period (1-35 days).
4. Optionally set a Backup window (a 30-minute slot in UTC).
5. Click Continue, choose Apply immediately, then Modify DB instance.

AWS CLI v2 equivalent:

aws rds modify-db-instance \
  --db-instance-identifier prod-mysql-01 \
  --backup-retention-period 14 \
  --preferred-backup-window 03:00-03:30 \
  --apply-immediately

Output:

{
    "DBInstance": {
        "DBInstanceIdentifier": "prod-mysql-01",
        "BackupRetentionPeriod": 14,
        "PreferredBackupWindow": "03:00-03:30",
        "DBInstanceStatus": "available"
    }
}

Manual snapshots

A manual snapshot is a backup you trigger yourself. The most important difference from automated backups: a manual snapshot persists until you explicitly delete it. It is not affected by the retention period and is not removed when you delete the database.

This makes manual snapshots the right tool for milestones you want to keep indefinitely — a pre-upgrade checkpoint, a quarterly compliance copy, or a “known good” baseline.

When to use this

Take a manual snapshot before any risky change (a major version upgrade, a large schema migration) and for any data you must retain longer than 35 days. Do not rely on them for second-by-second recovery — a manual snapshot only captures the moment it was taken, with no transaction logs in between.

Console steps:

1. In the RDS console, go to Databases and select your instance.
2. Click Actions > Take snapshot.
3. Enter a Snapshot name (for example prod-mysql-01-pre-upgrade).
4. Click Take snapshot.

AWS CLI v2 equivalent:

aws rds create-db-snapshot \
  --db-instance-identifier prod-mysql-01 \
  --db-snapshot-identifier prod-mysql-01-pre-upgrade

Output:

{
    "DBSnapshot": {
        "DBSnapshotIdentifier": "prod-mysql-01-pre-upgrade",
        "DBInstanceIdentifier": "prod-mysql-01",
        "SnapshotType": "manual",
        "Status": "creating",
        "AllocatedStorage": 100,
        "Engine": "mysql"
    }
}

Automated backups vs manual snapshots

Feature	Automated backups	Manual snapshots
Triggered by	RDS (daily, automatic)	You, on demand
Point-in-time recovery	Yes (every 5 min via logs)	No (single moment only)
Retention	1-35 days, then auto-deleted	Until you delete it
Deleted with the DB?	Yes (unless you take a final snapshot)	No, kept independently
Best for	Recent operational recovery	Long-term archival, milestones

Cost note: Backup storage up to the size of your database is free. Storage beyond that is billed at about $0.095 per GB-month (us-east-1, 2026). Old manual snapshots are a common source of surprise charges — they linger forever until deleted.

Restoring a backup

This is the part that surprises people most: you cannot restore in place. Every restore — whether from PITR or a snapshot — creates a brand-new DB instance with a brand-new endpoint (the DNS hostname your app connects to). The original instance is untouched.

That means after a restore you must update your application’s connection string to point at the new endpoint, or swap the endpoints by renaming instances.

Point-in-time restore

Console steps:

1. In RDS > Databases, select the source instance.
2. Click Actions > Restore to point in time.
3. Choose Latest restorable time or a Custom date and time.
4. Enter a new DB instance identifier (for example prod-mysql-01-restore).
5. Click Restore to point in time.

AWS CLI v2 equivalent:

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-mysql-01 \
  --target-db-instance-identifier prod-mysql-01-restore \
  --restore-time 2026-06-15T14:31:00Z

Output:

{
    "DBInstance": {
        "DBInstanceIdentifier": "prod-mysql-01-restore",
        "DBInstanceStatus": "creating",
        "Engine": "mysql",
        "Endpoint": {
            "Address": "prod-mysql-01-restore.abc123xyz.us-east-1.rds.amazonaws.com",
            "Port": 3306
        }
    }
}

Restore from a snapshot

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier prod-mysql-01-restore \
  --db-snapshot-identifier prod-mysql-01-pre-upgrade

Warning: When you delete an RDS instance, the console offers a “Create final snapshot?” checkbox. If you skip it, your automated backups are deleted along with the instance and the data is gone. Always take a final snapshot unless you are certain you will never need the data again.

Best practices

• Keep automated backups enabled on every production database, with a retention period of at least 7 days (14-35 for stricter recovery needs).
• Take a manual snapshot before every risky operation: major version upgrades, large migrations, and big bulk deletes.
• Always create a final snapshot when deleting an instance, unless the data is truly disposable.
• Use manual snapshots (or copy them to S3) for anything you must retain beyond 35 days.
• Periodically delete old manual snapshots you no longer need to avoid silent storage charges.
• Practice a restore in a non-production account at least once — confirm your team knows the endpoint changes and the app must be repointed.

Related Topics

• What is RDS?
• Create an RDS instance
• RDS Multi-AZ
• RDS read replicas
• Amazon Aurora