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

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.

Your DB instance must be in the ACTIVE state for automated backups to occur. If your database is in another state, for example STORAGE_FULL, automated backups do not occur.

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

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 or DB Cluster Snapshot. For more information about sharing a DB snapshot, see Sharing a DB Snapshot or DB Cluster Snapshot.

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 information on backup storage costs, see Amazon RDS Pricing.

All automated backups are deleted when you delete a DB instance. After you delete a DB instance, 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.

Manual snapshots are not deleted.

The 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 may 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 which is selected at random from an 8-hour block of time per region. The following table lists the time blocks for each region from which the default backups windows are assigned.

Region Time Block
US East (N. Virginia) Region 03:00–11:00 UTC
US East (Ohio) 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 (Mumbai) Region 16:30–00:30 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
EU (Frankfurt) Region 20:00–04:00 UTC
EU (Ireland) Region 22:00–06:00 UTC
EU (London) Region 06:00–14:00 UTC
South America (São Paulo) Region 23:00–07:00 UTC
AWS GovCloud (US) 03:00–11:00 UTC

The 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, or seven days if you create the DB instance using the AWS Console. For Amazon Aurora DB clusters, the default backup retention period is one day regardless of how the DB cluster is created. After you create a DB instance, you can modify the backup retention period. You can set the backup retention period to between 1 and 35 days. You can also set the backup retention period to 0, which 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 may 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.

AWS Management 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 DB Instances, and then select the DB instance that you want to modify.

  3. Choose Instance Actions, and then choose Modify. The Modify DB Instance window appears.

  4. For Backup Retention Period, choose 0.

  5. Select Apply Immediately.

  6. Choose Continue.

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

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:

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

For Windows:

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

Copy
aws rds describe-db-instances --db-instance-identifier mydbinstance

API

To disable automated backups immediately, call the Amazon RDS API action ModifyDBInstance with the following parameters:

  • DBInstanceIdentifier = mydbinstance

  • BackupRetentionPeriod = 0

Example

Copy
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, an outage occurs 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).

AWS Management 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 DB Instances, and then select the DB instance that you want to modify.

  3. Choose Instance Actions, and then choose Modify. The Modify DB Instance page appears.

  4. For Backup Retention Period, choose a positive non-zero value, for example 3.

  5. Select Apply Immediately.

  6. Choose Continue.

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

CLI

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

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

Include the following parameters:

  • --db-instance-identifier

  • --backup-retention-period

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

For Linux, OS X, or Unix:

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

For Windows:

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

API

To enable automated backups immediately, use the AWS CLI ModifyDBInstance command.

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

Include the following parameters:

  • DBInstanceIdentifier = mydbinstance

  • BackupRetentionPeriod = 3

  • ApplyImmediately = true

Example

Copy
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>

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, may lead to unreliable behavior while restoring from backups. Specifically, since storage engines like MyISAM do not 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 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 (see: http://dev.mysql.com/doc/refman/5.5/en/repair-table.html). However, as noted in the MySQL documentation, there is a good chance that you will not be able to recover all your data.

  • If you want to take a snapshot of your MyISAM tables prior to 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:

      Copy
      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:

      Copy
      mysql> UNLOCK TABLES;

    These steps force MyISAM to flush data stored in memory to disk thereby ensuring 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 for the XtraDB storage engine; 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 XtraDB tables, you can use 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 prior to 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.

Related Topics