Amazon Relational Database Service
User Guide (API Version 2014-10-31)

The AWS Documentation website is getting a new look!
Try it now and let us know what you think. Switch to the new look >>

You can return to the original look by selecting English in the language selector above.

Working With Backups

Amazon RDS creates and saves automated backups of your DB instance. Amazon RDS creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases.

Amazon RDS creates automated backups of your DB instance during the backup window of your DB instance. Amazon RDS saves the automated backups of your DB instance according to the backup retention period that you specify. If necessary, you can recover your database to any point in time during the backup retention period.

Automated backups follow these rules:

  • Your DB instance must be in the ACTIVE state for automated backups to occur. Automated backups don't occur while your DB instance is in a state other than ACTIVE, for example STORAGE_FULL.

  • Automated backups and automated snapshots don't occur while a copy is executing in the same region for the same DB instance.

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

The first snapshot of a DB instance contains the data for the full DB instance. Subsequent snapshots of the same DB instance 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 Snapshot. For more information about sharing a DB snapshot, see Sharing a DB Snapshot.

Note

You can also use AWS Backup to manage backups of Amazon RDS DB instances. Backups managed by AWS Backup are considered manual snapshots for the manual snapshot limit. For information about AWS Backup, see the AWS Backup Developer Guide.

Backup Storage

Your Amazon RDS backup storage for each region is composed of the automated backups and manual DB snapshots for that region. Your backup storage is equivalent to the sum of the database storage for all instances in that region. Moving a DB snapshot to another region increases the backup storage in the destination region.

For more information about backup storage costs, see Amazon RDS Pricing.

If you chose 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. Or 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.

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 is not 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 Multi-AZ deployments.

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

Region Time Block
US East (Ohio) Region 03:00–11:00 UTC
US East (N. Virginia) Region 03:00–11:00 UTC
US West (N. California) Region 06:00–14:00 UTC
US West (Oregon) Region 06:00–14:00 UTC
Asia Pacific (Hong Kong) Region 06:00–14:00 UTC
Asia Pacific (Mumbai) Region 16:30–00:30 UTC
Asia Pacific (Osaka-Local) Region 00:00–08:00 UTC
Asia Pacific (Seoul) Region 13:00–21:00 UTC
Asia Pacific (Singapore) Region 14:00–22:00 UTC
Asia Pacific (Sydney) Region 12:00–20:00 UTC
Asia Pacific (Tokyo) Region 13:00–21:00 UTC
Canada (Central) Region 06:29–14:29 UTC
China (Beijing) Region 06:00–14:00 UTC
China (Ningxia) Region 06:00–14:00 UTC
EU (Frankfurt) Region 20:00–04:00 UTC
EU (Ireland) Region 22:00–06:00 UTC
EU (London) Region 06:00–14:00 UTC
EU (Paris) Region 07:29–14:29 UTC
EU (Stockholm) Region 23:00–07:00 UTC
Middle East (Bahrain) Region 06:00–14:00 UTC
South America (São Paulo) Region 23:00–07:00 UTC
AWS GovCloud (US-West) 03:00–11:00 UTC

Backup Retention Period

You can set the backup retention period when you create a DB instance. 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 AWS CLI. The default backup retention period is seven days if you create the DB instance using the console. After you create a DB instance, you can modify the backup retention period. You can set the backup retention period to between 0 and 35 days. Setting the backup retention period to 0 disables automated backups. Manual snapshot limits (100 per region) do not apply to automated backups.

Important

An outage occurs if you change the backup retention period from 0 to a non-zero value or from a non-zero value to 0.

Disabling Automated Backups

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

Important

We highly discourage disabling automated backups because it disables point-in-time recovery. Disabling automatic backups for a DB instance deletes all existing automated backups for the instance. If you disable and then re-enable automated backups, you are only able to restore starting from the time you re-enabled automated backups.

In this example, you disable automated backups for a DB instance named mydbinstance by setting the backup retention parameter to 0.

Console

To disable automated backups immediately

  1. Sign in to the AWS Management Console and open the Amazon RDS console at https://console.aws.amazon.com/rds/.

  2. In the navigation pane, choose Databases, and then choose the DB instance that you want to modify.

  3. Choose Modify. The Modify DB Instance page appears.

  4. For Backup Retention Period, choose 0 days.

  5. Choose Continue.

  6. Choose Apply Immediately.

  7. On the confirmation page, choose Modify DB Instance to save your changes and disable automated backups.

AWS CLI

To disable automated backups immediately, use the modify-db-instance command and set the backup retention period to 0 with --apply-immediately.

The following example immediately disabled automatic backups.

For Linux, OS X, or Unix:

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

For Windows:

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

To know when the modification is in effect, call describe-db-instances for the DB instance until the value for backup retention period is 0 and mydbinstance status is available.

aws rds describe-db-instances --db-instance-identifier mydbinstance
RDS API

To disable automated backups immediately, call the ModifyDBInstance operation with the following parameters:

  • DBInstanceIdentifier = mydbinstance

  • BackupRetentionPeriod = 0

Example

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>

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 non-zero value. When automated backups are enabled, your RDS instance and database is taken offline and a backup is immediately created.

In this example, you enable automated backups for a DB instance named mydbinstance by setting the backup retention period to a positive non-zero value (in this case, 3).

Console

To enable automated backups immediately

  1. Sign in to the AWS Management Console and open the Amazon RDS console at https://console.aws.amazon.com/rds/.

  2. In the navigation pane, choose Databases, and then choose the DB instance that you want to modify.

  3. Choose Modify. The Modify DB Instance page appears.

  4. For Backup Retention Period, choose a positive nonzero value, for example 3 days.

  5. Choose Continue.

  6. Choose Apply Immediately.

  7. On the confirmation page, choose Modify DB Instance to save your changes and enable automated backups.

AWS CLI

To enable automated backups immediately, use the AWS CLI modify-db-instance command.

In this example, we enable automated backups by setting the backup retention period to three days.

Include the following parameters:

  • --db-instance-identifier

  • --backup-retention-period

  • --apply-immediately or --no-apply-immediately

For Linux, OS X, or Unix:

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

For Windows:

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

To enable automated backups immediately, use the RDS API ModifyDBInstance operation.

In this example, we enable automated backups by setting the backup retention period to three days.

Include the following parameters:

  • DBInstanceIdentifier

  • BackupRetentionPeriod

  • ApplyImmediately = true

Example

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

Retaining Automated Backups

When you delete a DB instance, you can retain automated backups.

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.

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

You can restore or remove retained automated backups using the AWS Management Console, RDS API, and AWS 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.

Restoration

To view your retained automated backups, switch to the automated backups page. You can view individual snapshots associated with a retained automated backup on the database snapshots page in the console. 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.

Restored DB instances are automatically associated with the default parameter and option groups. However, you can apply a custom parameter group and option group by specifying them during a restore.

In this example, you restore a DB instance to a point in time using the retained automated backup. First, you describe your retained automated backups, so you can see which of them to restore.

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

  • DBInstanceIdentifier

  • DbiResourceId

aws rds describe-db-instance-automated-backups --db-instance-identifier DBInstanceIdentifier OR aws rds describe-db-instance-automated-backups --dbi-resource-idDbiResourceId

Next, to restore your retained automated backup to a point in time, using the RDS API, call the RestoreDBInstanceToPointInTime action with the following parameters:

  • SourceDbiResourceId

  • TargetDBInstanceIdentifier

aws rds restore-db-instance-to-point-in-time --source-dbi-resource-id SourceDbiResourceId --target-db-instance-identifier TargetDBInstanceIdentifier --use-latest-restorable-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 and Recommendations

The following limitations apply to retained automated backups:

  • The maximum number of retained automated backups in one region is 20. It's not included in the DB instances limit. You can have 20 running DB instances and an additional 20 retained automated backups at the same time.

  • Retained automated backups don't contain information about parameters or option groups.

  • You can restore a deleted instance to a point in time that is within the retention period at the time of delete.

  • A retained automated backup can't be modified because it consists of system backups, transaction logs, and the DB instance properties that existed at the time you deleted the source instance.

Automated Backups with Unsupported MySQL Storage Engines

For the MySQL DB engine, automated backups are only supported for the InnoDB storage engine. Use of these features with other MySQL storage engines, including MyISAM, can lead to unreliable behavior while 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.

  • To convert existing MyISAM tables to InnoDB tables, you can use the ALTER TABLE command, for example: ALTER TABLE table_name ENGINE=innodb, ALGORITHM=COPY;

  • If you choose to use MyISAM, you can attempt to manually repair tables that become damaged after a crash by using the REPAIR command. For more information, see REPAIR TABLE Syntax in the MySQL documentation. However, as noted in the MySQL documentation, there is a good chance that you might not be able to recover all your data.

  • If you want to take a snapshot of your MyISAM tables before restoring, follow these steps:

    1. Stop all activity to your MyISAM tables (that is, close all sessions).

      You can close all sessions by calling the mysql.rds_kill command for each process that is returned from the SHOW FULL PROCESSLIST command.

    2. Lock and flush each of your MyISAM tables. For example, the following commands lock and flush two tables named myisam_table1 and myisam_table2:

      mysql> FLUSH TABLES myisam_table, myisam_table2 WITH READ LOCK;
    3. Create a snapshot of your DB instance. When the snapshot has completed, release the locks and resume activity on the MyISAM tables. You can release the locks on your tables using the following command:

      mysql> UNLOCK TABLES;

    These steps force MyISAM to flush data stored in memory to disk, which ensures a clean start when you restore from a DB snapshot. For more information on creating a DB snapshot, see Creating a DB Snapshot.

Automated Backups with Unsupported MariaDB Storage Engines

For the MariaDB DB engine, automated backups are only supported with the InnoDB storage engine (version 10.2 and later) and XtraDB storage engine (versions 10.0 and 10.1). Use of these features with other MariaDB storage engines, including Aria, might lead to unreliable behavior while 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 XtraDB storage engine.

  • To convert existing Aria tables to InnoDB tables, you can use the ALTER TABLE command. For example: ALTER TABLE table_name ENGINE=innodb, ALGORITHM=COPY;

  • To convert existing Aria tables to XtraDB tables, you can use the ALTER TABLE command. For example: ALTER TABLE table_name ENGINE=xtradb, ALGORITHM=COPY;

  • If you choose to use Aria, you can attempt to manually repair tables that become damaged after a crash by using the REPAIR TABLE command. For more information, see http://mariadb.com/kb/en/mariadb/repair-table/.

  • If you want to take a snapshot of your Aria tables before restoring, follow these steps:

    1. Stop all activity to your Aria tables (that is, close all sessions).

    2. Lock and flush each of your Aria tables.

    3. Create a snapshot of your DB instance. When the snapshot has completed, release the locks and resume activity on the Aria tables. These steps force Aria to flush data stored in memory to disk, thereby ensuring a clean start when you restore from a DB snapshot.