# Amazon Relational Database Service backups
<a name="rds-backup"></a>

## Amazon RDS and AWS Backup
<a name="rds-backup-differences"></a>

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 AWS resources, including Amazon RDS, offer their own native backup solutions.

Amazon RDS gives the option of making [automated backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html) and [manual backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingManualBackups.html). Recovery points created by AWS Backup are classified differently depending on the backup type:
+ **Periodic snapshots** created by AWS Backup are considered manual backups in Amazon RDS. These are snapshot-based backups taken according to your backup plan schedule.
+ **Continuous backups** created by AWS 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 AWS Backup to [create a backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#create-backup-plan-console) (recovery point) of an Amazon RDS instance, AWS Backup checks if you have previously used Amazon RDS to create an automated backup. If an automated backup exists, AWS Backup creates a incremental snapshot copy (`copy-db-snapshot` operation). If no backup exists, AWS Backup creates a snapshot of the instance you indicate, instead of a copy (`create-db-snapshot` operation).

The first snapshot made by AWS 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html#USER_CopySnapshot.Incremental) in the *Amazon RDS User Guide*.

**Important**  
When a AWS Backup backup plan is scheduled to create multiple daily snapshots of an Amazon RDS instance, and when one of those scheduled [AWS Backup Start Backup window](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#plan-options-and-configuration) coincides with the [Amazon RDS Backup window](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupWindow), the data lineage of the backups can branch off into non-identical backups, creating unplanned and conflicting backups. To prevent this, ensure your AWS Backup backup plan or Amazon RDS window do not coincide in their times.

### Considerations
<a name="rds-backup-considerations"></a>

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

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

## Amazon RDS continuous backups and point in time restore
<a name="rds-backup-continuous"></a>

Continuous backups involve using AWS 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](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html#point-in-time-recovery-supported-services) and [managing continuous backup settings](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html#point-in-time-recovery-managing) for more information.

## Amazon RDS Multi-Availability Zone backups
<a name="rds-multiaz"></a>

AWS 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.

For a list of Regions where Multi-Availability Zone backups are available, see the Amazon RDS Multi-AZ column in [Supported services by AWS Region](backup-feature-availability.md#supported-services-by-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 AWS 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](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html) (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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) in the *Amazon RDS User Guide*.

For more information on [ Creating a Multi-AZ DB cluster snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateMultiAZDBClusterSnapshot.html), see the Amazon RDS User Guide.

## Amazon Aurora Global Databases
<a name="rds-aurora-global"></a>

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