Database Backups and Point-in-Time Recovery

RDS instances are backed up automatically on a standard retention schedule. If
you need backups kept for longer or shorter, you can override the retention
period from the database Component's configuration in SVIEW.

Default retention period

If you have not set a custom value, automated backups are retained according to
the database's environment:

Aurora clusters use a longer production retention window than standard
(single-instance) RDS. Check which engine your database uses if you are unsure
which column applies.

Backups are disabled on DR instances by design. A DR instance is a copy of a
source database that is already being backed up, so a second automated backup
schedule would duplicate the data and the cost without adding recoverability.

Setting the retention period

Add a variables.backups_retention_period entry to the RDS Component's
configuration, giving the number of days to retain automated backups:

variables:
  backups_retention_period: 21

Click Save. The platform applies the new retention period to the instance.

⚠️

The AWS maximum is 35 days. Any value above that is rejected, so do not set
one. A value of 0 disables automated backups entirely — do not use it on any
instance holding data you need to recover.

If you need a copy retained beyond 35 days, raise a request: that requires
manual or exported snapshots rather than the automated backup window.

Restoring

For non-production databases you can restore from a snapshot yourself — see
RDS Restore from Snapshot. For production, raise a request
and the restore is run with you.

Cloud SQL instances have two recovery mechanisms, and both are set per database
Component:

• Automated backups — a full backup taken once a day in a fixed backup
  window. A set number of the most recent daily backups is kept, and the oldest
  is deleted when a new one is taken.
• Point-in-time recovery (PITR) — the database's transaction logs are kept
  for a set number of days, so the database can be recovered to any moment
  inside that window, not only to the time of a daily backup.

How long recovery points are kept

The edition is a property of the database instance. If you need to recover to an
exact moment more than 7 days ago, there are two ways to get there:

• Move the instance to Enterprise Plus, which allows a PITR window of up to
  35 days. The change restarts the instance briefly, so it is scheduled in a
  maintenance window, and Enterprise Plus costs more than Enterprise.
• Keep more daily backups. Raising the number of retained daily backups (for
  example to 35) gives one recovery point per day further back, at a small
  storage cost. Recovery between two daily backups is then not possible beyond
  the PITR window.

To see or change the number of retained backups, the PITR window or the edition
for your databases, raise a request.

Restoring

• From a daily backup — the backup can be restored to a new instance, which
  leaves the current database untouched, or over an existing instance, which
  replaces its contents.
• To a point in time — PITR always creates a new instance with the data as
  it was at the chosen moment. Your applications are then pointed at it, or the
  needed data is copied back.

Raise a request with the database name, the environment, and the time you want
to recover to (with its time zone). For production, the restore is run with you.

Restore tests

A backup is only proven when it has been restored. A restore test restores a
recent daily backup, and a chosen point in time, to a temporary instance, checks
the data, records how long it took, and then deletes the temporary instance.
Production data is not changed. Raise a request to schedule one; testing at least
once a quarter is a good baseline for production databases.