How do you test an Amazon RDS backup restore, step by step?

What do you need before testing an RDS restore?

You need automated backups turned on for the source instance, an IAM role that can restore and delete RDS instances, the subnet group and security group you want the test copy to use, and a way to connect privately, such as a bastion host or a task running inside the VPC.

Check your backup retention first. RDS automated backups can be kept for 1 to 35 days, and point-in-time restore is only possible within that window.

aws rds describe-db-instances \
  --db-instance-identifier prod-db \
  --query 'DBInstances[0].[BackupRetentionPeriod,LatestRestorableTime]'

Step 1: How do you start an RDS point-in-time restore for a test?

Start a point-in-time restore to a new instance with an obvious name. Set the network, security group and parameter group explicitly rather than relying on defaults, and keep it private.

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-db \
  --target-db-instance-identifier restore-test-2026-10 \
  --use-latest-restorable-time \
  --db-instance-class db.t4g.medium \
  --db-subnet-group-name private-db-subnets \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-parameter-group-name prod-db-params \
  --no-publicly-accessible \
  --no-multi-az \
  --tags Key=purpose,Value=restore-test

To test a specific moment instead of the latest, replace --use-latest-restorable-time with --restore-time 2026-10-16T09:00:00Z. To test a snapshot rather than continuous backups, use restore-db-instance-from-db-snapshot. For Aurora, restore the cluster with restore-db-cluster-to-point-in-time, then add an instance to it with create-db-instance.

A smaller instance class keeps the test cheap, but if you want the timing to reflect a real recovery, test at least once a year on the same class as production.

Step 2: How do you know when the restored RDS instance is ready?

Use the built-in waiter, and note the start and end times. Those times are your measured restore duration.

date -u
aws rds wait db-instance-available \
  --db-instance-identifier restore-test-2026-10
date -u

Step 3: What should you check in the restored RDS data?

Check that the data is complete and as recent as you expect.

Pick a handful of tables that matter to your business and compare them with production.

-- Newest record should be close to the restore point
SELECT max(created_at) FROM orders;

-- Row counts on key tables, compared with production
SELECT count(*) FROM users;
SELECT count(*) FROM orders;

-- Schema version matches what production runs
SELECT * FROM schema_migrations ORDER BY version DESC LIMIT 1;

• The newest record is within your RPO of the restore point.
• Row counts are close to production at that moment.
• The latest migration is present.
• Required extensions, roles and permissions exist.

Step 4: Does your application work on the restored RDS database?

Point a test copy of your application, or a one-off task, at the restored endpoint and run a short smoke test: start the app, log in as a test user, load a page that reads from several tables.

This catches problems the SQL checks miss, such as missing database users or settings your app depends on.

Never point production at the test copy, and make sure the test copy cannot send emails or charge cards. Use a test configuration with outbound integrations switched off.

Step 5: How do you clean up after an RDS restore test?

Delete the test instance as soon as you have your results, so it does not keep billing.

aws rds delete-db-instance \
  --db-instance-identifier restore-test-2026-10 \
  --skip-final-snapshot \
  --delete-automated-backups

Then write the one-page report: what you restored, how long it took, what you checked and what needs fixing. The backup proof guide has a template list of what to include.

How long does an RDS restore take?

There is no fixed answer. RDS restore time depends mainly on the size of the database, how much transaction log must be replayed to reach your chosen point in time, and the instance class you restore to.

Small databases often restore in minutes, while large ones can take much longer. The only reliable number is the one you measure in your own account, which is a good reason to time every test.

How do you automate RDS restore validation?

You can automate RDS restore validation with AWS Backup restore testing plus a validation Lambda, or with a scheduled pipeline that runs the restore, the checks and the cleanup.

There are two common ways to automate it.

Whichever you choose, the automation must fail loudly. A restore test that fails silently is worse than none, because it creates false confidence. Send the result to a channel people read.

Are you ready to run an RDS restore test?

Tick each item before you start the first test.

Does restoring an RDS backup affect the production database?

No. An RDS restore always creates a new DB instance from the backup data.

The source instance keeps running and is not changed. The only production risks come from how you use the copy: pointing an application with live integrations at it, or exposing it publicly. Keep the copy private and use a test configuration.

Should you test the latest RDS backup or an older one?

Both, at different times. Restoring the latest point proves your newest data is protected, which matches the most common real incident.

Occasionally restoring an older point, such as a week ago, proves your retention works and that older backups are not silently broken. Rotate between them so every test adds new information.