RDS Restore from Snapshot

You want to put an RDS database back to the state captured in a snapshot — for
example after a failed migration. The platform provides an automated restore for
AWS environments: a Lambda function deployed into your own environment performs
the restore, so you do not need infrastructure-level access to run it.

The function is idempotent. If it exceeds the 15-minute Lambda timeout, invoke it
again and it continues from where it stopped.

When to use this

• Returning a dev or staging database to a known-good state after a failed
  migration.
• Recovering from accidental data deletion in a non-production environment.
• Testing your application against a production data snapshot in a lower
  environment.

Before you start

• AWS Console access to your own account, with permission to view Lambda
  and CloudWatch. You need it to invoke the function and to watch the
  progress. If your team does not have Console access, raise a request and CTO2B
  will run the restore for you instead — the rest of this article is then not
  needed.
• The rds-autorestore image in ECR, in the same AWS region as the
  database. A Lambda function cannot pull an image from another region. If the
  image is not in that region, raise a request and CTO2B will push it.
• The source database must still exist. The function copies the source
  database's subnet group, parameter group, option group and security groups to
  the restored copy, and does nothing if the source is missing. If the database
  has already been deleted, raise a request instead.
• The snapshot identifier you want to restore from, found in the AWS Console
  under RDS → Snapshots, or by asking in your Slack channel.

Step 1 — deploy the restore Lambda

1. In SVIEW, open the Service where the restore should run.

2. Go to Applications → Deployments and click + New. Under ENVIRONMENTS, select the Environment; then, under APPLICATIONS, select RDS Auto Restore.

   

3. Configure the required values:

   YAML

   image_uri: <your-account-id>.dkr.ecr.<region>.amazonaws.com/rds-autorestore:<tag>
   
   environment_variables:
     SOURCE_DB: "<rds-instance-identifier>"
     SNAPSHOT_ID: "<snapshot-identifier>"

   • SOURCE_DB is the RDS instance identifier, exactly as shown in the AWS
     Console under RDS → Databases — not the Component name in SVIEW.
   • Use the image tag CTO2B provides. Ask in your Slack channel if you do not
     have it; do not simply pick the newest tag in the repository.

4. Click Save and wait for the Component to reach a healthy status.

Step 2 — invoke the Lambda

1. In the AWS Console, go to Lambda → Functions.
2. Find the restore function. Its name is a shortened form of the Component name
   ending in -aws-lbd — for example <stage>-<env>-share-<inst>-aws-lbd — so
   search for -aws-lbd rather than for the full Component name.
3. Click Test. The event JSON is ignored.
4. Click Test again to invoke it.

Follow progress in CloudWatch → Log Groups, searching for the Lambda function
name. A restore usually takes 10 to 30 minutes depending on database size.

Step 3 — re-apply the database configuration

Once the restore completes, increment the rev field in the database
Component's configuration and click Save:

terraform:
  variables:
    rev: 6    # increment each time you restore

rev does not change the database itself. Incrementing it makes the platform
re-apply the database Component's configuration, which brings back settings the
restore does not copy, such as backup retention, enhanced monitoring and storage
autoscaling. It must sit under terraform.variables; a rev under
terraform.spec.variables never reaches the configuration and has no effect.

Step 4 — clean up

After a successful restore, delete the RDS Auto Restore Component
in SVIEW. It holds permission to delete RDS instances, so it should not be left
in place once the restore is done.

Verify it worked

• The database Component returns to a healthy status in SVIEW.
• Your application reconnects, and the restored data matches the point in time
  you expected.
• Database users have the passwords they had when the snapshot was taken. If
  passwords were rotated since then, or the application cannot log in after the
  restore, raise a request and CTO2B will re-sync them.

Common issues

If the issue persists, raise a request with the database name, the snapshot
identifier, and the CloudWatch log output.

Related articles

• Database Backups and Point-in-Time Recovery
• Disaster Recovery Plan and DR Testing
• Restart an Application or a Single Pod