Working with backups

Amazon RDS creates and saves automated backups of your DB instance or Multi-AZ DB cluster during the backup window of your DB instance. RDS creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases. RDS saves the automated backups of your DB instance according to the backup retention period that you specify. If necessary, you can recover your DB instance to any point in time during the backup retention period.

Automated backups follow these rules:

You can also back up your DB instance manually by creating a DB snapshot. For more information about manually creating a DB snapshot, see Creating a DB snapshot.

The first snapshot of a DB instance contains the data for the full database. Subsequent snapshots of the same database are incremental, which means that only the data that has changed after your most recent snapshot is saved.

You can copy both automatic and manual DB snapshots, and share manual DB snapshots. For more information about copying a DB snapshot, see Copying a DB snapshot. For more information about sharing a DB snapshot, see Sharing a DB snapshot.

Backup storage

Your Amazon RDS backup storage for each Amazon Web Services Region is composed of the automated backups and manual DB snapshots for that Region. Total backup storage space equals the sum of the storage for all backups in that Region. Moving a DB snapshot to another Region increases the backup storage in the destination Region. Backups are stored in Amazon S3.

If you choose to retain automated backups when you delete a DB instance, the automated backups are saved for the full retention period. If you don't choose Retain automated backups when you delete a DB instance, all automated backups are deleted with the DB instance. After they are deleted, the automated backups can't be recovered. If you choose to have Amazon RDS create a final DB snapshot before it deletes your DB instance, you can use that to recover your DB instance. Optionally, you can use a previously created manual snapshot. Manual snapshots are not deleted. You can have up to 100 manual snapshots per Region.

Backup window

Automated backups occur daily during the preferred backup window. If the backup requires more time than allotted to the backup window, the backup continues after the window ends until it finishes. The backup window can't overlap with the weekly maintenance window for the DB instance or Multi-AZ DB cluster.

During the automatic backup window, storage I/O might be suspended briefly while the backup process initializes (typically under a few seconds). You might experience elevated latencies for a few minutes during backups for Multi-AZ deployments. For MariaDB, MySQL, Oracle, and PostgreSQL, I/O activity isn't suspended on your primary during backup for Multi-AZ deployments because the backup is taken from the standby. For SQL Server, I/O activity is suspended briefly during backup for both Single-AZ and Multi-AZ deployments because the backup is taken from the primary.

Automated backups might occasionally be skipped if the DB instance or cluster has a heavy workload at the time a backup is supposed to start. If a backup is skipped, you can still do a point-in-time-recovery (PITR), and a backup is still attempted during the next backup window. For more information on PITR, see Restoring a DB instance to a specified time.

If you don't specify a preferred backup window when you create the DB instance or Multi-AZ DB cluster, Amazon RDS assigns a default 30-minute backup window. This window is selected at random from an 8-hour block of time for each Amazon Web Services Region. The following table lists the time blocks for each Amazon Web Services Region from which the default backup windows are assigned.

Backup retention period

You can set the backup retention period when you create a DB instance or Multi-AZ DB cluster. If you don't set the backup retention period, the default backup retention period is one day if you create the DB instance using the Amazon RDS API or the Amazon CLI. The default backup retention period is seven days if you create the DB instance using the console.

After you create a DB instance or cluster, you can modify the backup retention period. You can set the backup retention period of a DB instance to between 0 and 35 days. Setting the backup retention period to 0 disables automated backups. You can set the backup retention period of a multi-AZ DB cluster to between 1 and 35 days. Manual snapshot limits (100 per Region) don't apply to automated backups.

Automated backups aren't created while a DB instance or cluster is stopped. Backups can be retained longer than the backup retention period if a DB instance has been stopped. RDS doesn't include time spent in the stopped state when the backup retention window is calculated.

Enabling automated backups

If your DB instance doesn't have automated backups enabled, you can enable them at any time. You enable automated backups by setting the backup retention period to a positive nonzero value. When automated backups are turned on, your DB instance is taken offline and a backup is immediately created.

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance  \
    --backup-retention-period 3 \
    --apply-immediately

aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance  ^
    --backup-retention-period 3 ^
    --apply-immediately

Viewing automated backups

To view your automated backups, choose Automated backups in the navigation pane. To view individual snapshots associated with an automated backup, choose Snapshots in the navigation pane. Alternatively, you can describe individual snapshots associated with an automated backup. From there, you can restore a DB instance directly from one of those snapshots.

To describe the automated backups for your existing DB instances using the Amazon CLI, use one of the following commands:

aws rds describe-db-instance-automated-backups --db-instance-identifier DBInstanceIdentifier

or

aws rds describe-db-instance-automated-backups --dbi-resource-id DbiResourceId

To describe the retained automated backups for your existing DB instances using the RDS API, call the DescribeDBInstanceAutomatedBackups action with one of the following parameters:

Retaining automated backups

When you delete a DB instance, you can choose to retain automated backups. Automated backups can be retained for a number of days equal to the backup retention period configured for the DB instance at the time when you delete it.

Retained automated backups contain system snapshots and transaction logs from a DB instance. They also include your DB instance properties like allocated storage and DB instance class, which are required to restore it to an active instance.

Retained automated backups and manual snapshots incur billing charges until they're deleted. For more information, see Retention costs.

You can retain automated backups for RDS instances running the MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server engines.

You can restore or remove retained automated backups using the Amazon Web Services Management Console, RDS API, and Amazon CLI.

Retention period

The system snapshots and transaction logs in a retained automated backup expire the same way that they expire for the source DB instance. Because there are no new snapshots or logs created for this instance, the retained automated backups eventually expire completely. Effectively, they live as long their last system snapshot would have done, based on the settings for retention period the source instance had when you deleted it. Retained automated backups are removed by the system after their last system snapshot expires.

You can remove a retained automated backup in the same way that you can delete a DB instance. You can remove retained automated backups using the console or the RDS API operation DeleteDBInstanceAutomatedBackup.

Final snapshots are independent of retained automated backups. We strongly suggest that you take a final snapshot even if you retain automated backups because the retained automated backups eventually expire. The final snapshot doesn't expire.

Viewing retained backups

To view your retained automated backups, choose Automated backups in the navigation pane, then choose Retained. To view individual snapshots associated with a retained automated backup, choose Snapshots in the navigation pane. Alternatively, you can describe individual snapshots associated with a retained automated backup. From there, you can restore a DB instance directly from one of those snapshots.

To describe your retained automated backups using the Amazon CLI, use the following command:

aws rds describe-db-instance-automated-backups --dbi-resource-id DbiResourceId

To describe your retained automated backups using the RDS API, call the DescribeDBInstanceAutomatedBackups action with the DbiResourceId parameter.

Restoration

For information on restoring DB instances from automated backups, see Restoring a DB instance to a specified time.

Retention costs

The cost of a retained automated backup is the cost of total storage of the system snapshots that are associated with it. There is no additional charge for transaction logs or instance metadata. All other pricing rules for backups apply to restorable instances.

For example, suppose that your total allocated storage of running instances is 100 GB. Suppose also that you have 50 GB of manual snapshots plus 75 GB of system snapshots associated with a retained automated backup. In this case, you are charged only for the additional 25 GB of backup storage, like this: (50 GB + 75 GB) – 100 GB = 25 GB.

Limitations

The following limitations apply to retained automated backups:

Deleting retained automated backups

You can delete retained automated backups when they are no longer needed.

aws rds delete-db-instance-automated-backup \
    --dbi-resource-id db-123ABCEXAMPLE

aws rds delete-db-instance-automated-backup ^
    --dbi-resource-id db-123ABCEXAMPLE

Disabling automated backups

You might want to temporarily disable automated backups in certain situations, for example while loading large amounts of data.

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --backup-retention-period 0 \
    --apply-immediately

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --backup-retention-period 0 ^
    --apply-immediately

aws rds describe-db-clusters --db-cluster-identifier mydcluster

https://rds.amazonaws.com/
    ?Action=ModifyDBInstance
    &DBInstanceIdentifier=mydbinstance
    &BackupRetentionPeriod=0
    &SignatureVersion=2
    &SignatureMethod=HmacSHA256
    &Timestamp=2009-10-14T17%3A48%3A21.746Z
    &AWSAccessKeyId=<&AWS; Access Key ID>
    &Signature=<Signature>

Using Amazon Backup to manage automated backups

Amazon Backup is a fully managed backup service that makes it easy to centralize and automate the backup of data across Amazon services in the cloud and on premises. You can manage backups of your Amazon RDS databases in Amazon Backup.

To enable backups in Amazon Backup, use resource tagging to associate your database with a backup plan. For more information, see Using tags to enable backups in Amazon Backup.

For more information about Amazon Backup, see the Amazon Backup Developer Guide.

Automated backups with unsupported MySQL storage engines

For the MySQL DB engine, automated backups are only supported for the InnoDB storage engine. Using these features with other MySQL storage engines, including MyISAM, can lead to unreliable behavior when you're restoring from backups. Specifically, since storage engines like MyISAM don't support reliable crash recovery, your tables can be corrupted in the event of a crash. For this reason, we encourage you to use the InnoDB storage engine.

Automated backups with unsupported MariaDB storage engines

For the MariaDB DB engine, automated backups are only supported with the InnoDB storage engine. Using these features with other MariaDB storage engines, including Aria, can lead to unreliable behavior when you're restoring from backups. Even though Aria is a crash-resistant alternative to MyISAM, your tables can still be corrupted in the event of a crash. For this reason, we encourage you to use the InnoDB storage engine.