Amazon Relational Database Service backups - Amazon Backup
Amazon RDS and Amazon Backup snapshotsAmazon RDS and Amazon Backup continuous backups and PITRAmazon RDS Multi-AZ backupsAmazon Aurora Global Databases
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Amazon Relational Database Service backups

Amazon RDS and Amazon Backup

When you consider the options to back up your Amazon RDS instances and clusters, it's important to clarify which kind of backup you want to create and use. Several Amazon resources, including Amazon RDS, offer their own native backup solutions.

Amazon RDS gives the option of making automated backups and manual backups. Recovery points created by Amazon Backup are classified differently depending on the backup type:

  • Periodic snapshots created by Amazon Backup are considered manual backups in Amazon RDS. These are snapshot-based backups taken according to your backup plan schedule.

  • Continuous backups created by Amazon Backup are considered automated backups in Amazon RDS. These enable point-in-time restore (PITR) by maintaining transaction logs alongside automated snapshots.

This distinction is important because manual and automated backups have different retention behaviors and lifecycle management in Amazon RDS.

When you use Amazon Backup to create a backup (recovery point) of an Amazon RDS instance, Amazon Backup checks if you have previously used Amazon RDS to create an automated backup. If an automated backup exists, Amazon Backup creates a incremental snapshot copy (copy-db-snapshot operation). If no backup exists, Amazon Backup creates a snapshot of the instance you indicate, instead of a copy (create-db-snapshot operation).

The first snapshot made by Amazon Backup, created by either operation, will result in 1 full snapshot. All subsequent copies of this will be incremental backups, as long as the full backup exists.

When using cross account or cross Region copies, incremental snapshot copy jobs process faster than full snapshot copy jobs. Keeping a previous snapshot copy until the new copy job is complete may reduce the copy job duration. If you choose to copy snapshots from RDS database instances, it is important to note that deleting previous copies first will cause full snapshot copies to be made (instead of incremental). For more information on optimizing copying, see Incremental snapshot copying in the Amazon RDS User Guide.

Important

When a Amazon Backup backup plan is scheduled to create multiple daily snapshots of an Amazon RDS instance, and when one of those scheduled Amazon Backup Start Backup window coincides with the Amazon RDS Backup window, the data lineage of the backups can branch off into non-identical backups, creating unplanned and conflicting backups. To prevent this, ensure your Amazon Backup backup plan or Amazon RDS window do not coincide in their times.

Considerations

RDS Custom for SQL Server and RDS Custom for Oracle are not currently supported by Amazon Backup.

Amazon Backup does not support backup and restore of RDS on Outposts.

Amazon RDS continuous backups and point in time restore

Continuous backups involve using Amazon Backup to create a full backup of your Amazon RDS resource, then capturing all changes through a transaction log. You can achieve a greater granularity by rewinding to the point in time you desire to restore to instead of choosing a previous snapshot taken at fixed time intervals.

See continuous backups and PITR supported services and managing continuous backup settings for more information.

Amazon RDS Multi-Availability Zone backups

Amazon Backup backs up and supports Amazon RDS for MySQL and for PostgreSQL Multi-AZ (Availability Zone) deployment options with one primary and two readable standby database instances.

Multi-Availability Zone backups are available in the following regions: Asia Pacific (Sydney) Region, Asia Pacific (Tokyo) Region, Europe (Ireland) Region, US East (Ohio) Region, US West (Oregon) Region, Europe (Stockholm) Region, Asia Pacific (Singapore) Region, US East (N. Virginia) Region, and Europe (Frankfurt) Region.

The Multi-AZ deployment option optimizes write transactions and is ideal when your workloads require additional read capacity, lower write transaction latency, more resilience from network jitter (which impacts the consistency of write transaction latency), and high availability and durability.

To create a Multi-AZ cluster, you can choose either MySQL or PostgreSQL as the engine type.

In the Amazon Backup console, there are three deployment options:

  • Multi-AZ DB cluster: Creates a DB cluster with a primary DB instances and two readable standby DB instances, which each DB instance in a different Availability Zone. Provides high availability, data redundancy, and increases capacity to server-ready workloads.

  • Multi-AZ DB instance: Creates a primary DB instance and a standby DB instance in a different Availability Zone. This provides high availability and data redundancy, but the standby DB instance doesn’t support connections for read workloads.

  • Single DB instance: Creates a single DB instance with no standby DB instances.

Backup behavior with instances and clusters

  • Point-in-Time Recovery (PITR) can support instances, but not clusters.

  • Copying a Multi-AZ DB cluster snapshot is not supported.

  • The Amazon Resource Name (ARN) for an RDS recovery point depends on whether an instance or cluster is used:

    An RDS instance ARN: arn:aws:rds:region: account:db:name

    An RDS Multi-Availability Cluster: arn:aws:rds:region:account:cluster:name

For more information, consult Multi-AZ DB cluster deployments in the Amazon RDS User Guide.

For more information on Creating a Multi-AZ DB cluster snapshot, see the Amazon RDS User Guide.

Amazon Aurora Global Databases

Amazon recommends maintaining backups in every Region where your global database is deployed.