自動バックアップの管理

このセクションでは、DB インスタンスと DB クラスターの自動バックアップを管理する方法について説明します。

トピック

• バックアップウィンドウ
• バックアップの保存期間
• 自動バックアップの有効化
• 自動バックアップの保持
• 保持している自動バックアップの削除
• 自動バックアップの無効化
• サポートされない MySQL ストレージエンジンを使用した自動バックアップ
• サポートされない MariaDB ストレージエンジンを使用した自動バックアップ
• 別の AWS リージョン への自動バックアップのレプリケーション

バックアップウィンドウ

自動バックアップは、優先されるバックアップウィンドウ中に毎日行われます。バックアップ期間に割り当てられた時間より長い時間がバックアップに必要な場合、期間が終了した後もバックアップが完了するまでバックアップが継続します。バックアップ期間は、DB インスタンスまたはマルチ AZ DB クラスターの週 1 回のメンテナンス期間と重複させることはできません。

自動バックアップウィンドウ中、バックアッププロセスのスタート時にストレージ I/O が一時中断することがあります (通常は数秒間)。マルチ AZ 配置のバックアップ中は、レイテンシーが数分間高くなることがあります。MariaDB、MySQL、Oracle、PostgreSQL の場合、バックアップはスタンバイから取られるため、マルチ AZ 配置のバックアップ中、プライマリの I/O アクティビティは中断しません。SQL Server の場合、バックアップはプライマリから取られるため、シングル AZ 配置とマルチ AZ 配置のバックアップ中に I/O アクティビティが短時間だけ中断します。Db2 では、バックアップがスタンバイから取得されている場合でも、バックアップ中に I/O アクティビティが短時間、中断されます。

バックアップが開始するときに、DB インスタンスまたはクラスターの負荷が大きい場合、自動バックアップがスキップされることがあります。バックアップがスキップされた場合でも、ポイントインタイムリカバリ (PITR) を実行し、次のバックアップウィンドウ中にバックアップを試行できます。PITR の詳細については「特定の時点への DB インスタンスの復元」を参照してください。

DB インスタンスまたはマルチ AZ DB クラスターの作成時に優先バックアップ期間を指定しなかった場合、Amazon RDS によってデフォルトの 30 分のバックアップ期間が割り当てられます。この期間は、各 AWS リージョン の 8 時間の時間ブロックからランダムに選択されます。次の表は、デフォルトのバックアップ期間が割り当てられる各 AWS リージョン の時間ブロックを示しています。

リージョン名	リージョン	時間ブロック
米国東部 (オハイオ)	us-east-2	03:00～11:00 UTC
米国東部 (バージニア北部)	us-east-1	03:00～11:00 UTC
米国西部 (北カリフォルニア)	us-west-1	06:00～14:00 UTC
米国西部 (オレゴン)	us-west-2	06:00～14:00 UTC
アフリカ (ケープタウン)	af-south-1	03:00～11:00 UTC
アジアパシフィック (香港)	ap-east-1	06:00～14:00 UTC
アジアパシフィック (ハイデラバード)	ap-south-2	06:30～14:30 UTC
アジアパシフィック (ジャカルタ)	ap-southeast-3	08:00～16:00 UTC
アジアパシフィック (メルボルン)	ap-southeast-4	11:00～19:00 UTC
アジアパシフィック（ムンバイ）	ap-south-1	16:30～00:30 UTC
アジアパシフィック (大阪)	ap-northeast-3	00:00～08:00 UTC
アジアパシフィック (ソウル)	ap-northeast-2	13:00～21:00 UTC
アジアパシフィック (シンガポール)	ap-southeast-1	14:00～22:00 UTC
アジアパシフィック (シドニー)	ap-southeast-2	12:00～20:00 UTC
アジアパシフィック (東京)	ap-northeast-1	13:00～21:00 UTC
カナダ (中部)	ca-central-1	03:00～11:00 UTC
カナダ西部 (カルガリー)	ca-west-1	18:00～02:00 UTC
中国 (北京)	cn-north-1	06:00～14:00 UTC
中国 (寧夏)	cn-northwest-1	06:00～14:00 UTC
欧州 (フランクフルト)	eu-central-1	20:00～04:00 UTC
欧州 (アイルランド)	eu-west-1	22:00～06:00 UTC
欧州 (ロンドン)	eu-west-2	22:00～06:00 UTC
欧州 (ミラノ)	eu-south-1	13:00～21:00 UTC
欧州 (パリ)	eu-west-3	07:29～14:29 UTC
欧州 (スペイン)	eu-south-2	13:00～21:00 UTC
欧州 (ストックホルム)	eu-north-1	23:00～07:00 UTC
欧州 (チューリッヒ)	eu-central-2	13:00～21:00 UTC
イスラエル (テルアビブ)	il-central-1	03:00～11:00 UTC
中東 (バーレーン)	me-south-1	06:00～14:00 UTC
中東 (アラブ首長国連邦)	me-central-1	05:00～13:00 UTC
南米（サンパウロ）	sa-east-1	23:00～07:00 UTC
AWS GovCloud (米国東部)	us-gov-east-1	01:00～09:00 UTC
AWS GovCloud (米国西部)	us-gov-west-1	06:00～14:00 UTC

バックアップの保存期間

DB インスタンスまたはマルチ AZ DB クラスターを作成するときに、バックアップ保持期間を設定できます。Amazon RDS API または AWS CLI を使用して DB インスタンスを作成し、バックアップ保持期間を設定しない場合、デフォルトのバックアップ保持期間は 1 日です。コンソールを使用して DB インスタンスを作成する場合、デフォルトのバックアップ保持期間は 7 日です。

DB インスタンスまたはクラスターを作成した後、バックアップ保持期間を変更できます。DB インスタンスのバックアップ保持期間は、0 ～ 35 日間で設定できます。バックアップ保持期間を 0 に設定すると、自動バックアップが無効になります。マルチ AZ DB クラスターのバックアップ保持期間は、1 ～ 35 日の間で設定できます。手動スナップショットの制限 (リージョンごとに 100) は、自動バックアップには適用されません。

DB インスタンスまたはクラスターの停止中は、自動バックアップは作成されません。DB インスタンスが停止している場合、バックアップ保持期間より長くバックアップを保持できます。RDSには、バックアップ保存期間の計算時にstopped状態にあった時間は含まれません。

重要

DB インスタンスのバックアップ保持期間を 0 から 0 以外の値、または 0 以外の値から 0 に変更すると、停止します。

自動バックアップの有効化

DB インスタンスで自動バックアップが有効になっていない場合、いつでも有効にすることができます。バックアップ保持期間を 0 以外の正の値に設定することで自動バックアップを有効にします。自動バックアップが有効なとき、DB インスタンスがオフラインになり、ただちにバックアップが作成されます。

注記

AWS Backup でバックアップを管理している場合、自動バックアップを有効にすることはできません。詳細については、「自動バックアップの管理に AWS Backup を使用する」を参照してください。

コンソール

自動バックアップをすぐに有効にするには

1. AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。

2. ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスまたはマルチ AZ DB クラスターを選択します。

3. Modify を選択します。

4. [バックアップ保持期間] で、ゼロ以外の正の値 (3 日など) を選択します。

5. [Continue] を選択します。

6. [Apply immediately] (すぐに適用) を選択します。

7. [DB インスタンスの変更] または [クラスターの変更] を選択して変更を保存し、自動バックアップを有効にします。

AWS CLI

自動バックアップを有効にするには、AWS CLI の modify-db-instance または modify-db-cluster コマンドを使用します。

以下のパラメータを含めます。

• --db-instance-identifier (またはマルチ AZ DB クラスターの場合は --db-cluster-identifier)

• --backup-retention-period

• --apply-immediately 、、または --no-apply-immediately

次の例では、バックアップ保持期間を 3 日に設定して、自動バックアップを有効にします。変更はすぐに適用されます。

Linux、macOS、Unix の場合:

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

Windows の場合:

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

RDS API

自動バックアップを有効にするには、次の必須パラメータを指定して RDS API ModifyDBInstance または ModifyDBCluster オペレーションを使用します。

• DBInstanceIdentifier 、、または DBClusterIdentifier

• BackupRetentionPeriod

自動バックアップの表示

自動バックアップを表示するには、ナビゲーションペインで「自動バックアップ」を選択します。自動バックアップに関連付けられている個々のスナップショットを表示するには、ナビゲーションペインで 「Snapshots」 (スナップショット) を選択します。または、自動バックアップに関連付けられた個別のスナップショットを説明できます。そのページで、スナップショットのいずれかから DB インスタンスを直接復元できます。

AWS CLI を使用してDB インスタンスに既存の自動バックアップを説明するには、次のいずれかのコマンドを使用します。

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

または

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

RDS API を使用して保持されている自動バックアップを説明するには、以下のパラメータのいずれかを指定して DescribeDBInstanceAutomatedBackups アクションを呼び出します。

• DBInstanceIdentifier

• DbiResourceId

自動バックアップの保持

注記

DB インスタンスの自動バックアップのみを保持でき、マルチ AZ DB クラスターは保持できません。

DB インスタンスを削除するときに、自動バックアップを保持することを選択できます。自動バックアップは、DB インスタンスの削除時に設定したバックアップ保持期間と同じ日数だけ保持されます。

保持されている自動バックアップには、DB インスタンスからのシステムスナップショットとトランザクションログが含まれます。割り当て済みストレージや DB インスタンスクラスなど、アクティブなインスタンスに復元するために必要な DB インスタンスプロパティも含まれます。

自動バックアップと手動スナップショットを保持すると、削除されるまで請求が発生します。詳細については、「保持コスト」を参照してください。

Db2、MariaDB、MySQL、PostgreSQL、Oracle、および Microsoft SQL Server の各エンジンを実行している RDS インスタンスの自動バックアップを保持できます。

AWS Management Console、RDS API、および AWS CLI を使用すると、保持されている自動バックアップを復元または削除できます。

保持期間

保持されている自動バックアップのシステムスナップショットやトランザクションログは、ソース DB インスタンスの期限切れと同じ方法で期限切れになります。このインスタンス用に作成された新しいスナップショットやログがないため、保持されている自動バックアップは最終的には完全に期限切れになります。実際には、ソースインスタンスを削除したときに設定されていた保持期間の設定に基づいて、最後のシステムスナップショットが実行されている間は存続します。保持されている自動バックアップは、最後のシステムスナップショットの有効期限が切れると、システムによって削除されます。

保持されている自動バックアップは、DB インスタンスを削除するのと同じ方法で削除できます。コンソールまたは RDS API オペレーション DeleteDBInstanceAutomatedBackup を使用すると、保持されている自動バックアップを削除できます。

最終スナップショットは、保持されている自動バックアップから独立しています。自動バックアップを保持している場合でも、保持されている自動バックアップは最終的に期限切れになるため、最終スナップショットを作成しておくことを強くお勧めします。最終スナップショットに有効期限はありません。

保持されたバックアップの表示

保持されている自動バックアップを表示するには、ナビゲーションペインで [Automated backups] (自動バックアップ) を選択し、[Retained] (保持) を選択します。保持された自動バックアップに関連付けられている個々のスナップショットを表示するには、ナビゲーションペインで [Snapshots] (スナップショット) を選択します。または、保持されている自動バックアップに関連付けられた個別のスナップショットを記述できます。そのページで、スナップショットのいずれかから DB インスタンスを直接復元できます。

AWS CLI を使用して保持されている自動バックアップを説明するには、次のいずれかのコマンドを使用します。

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

RDS API を使用して保持されている自動バックアップを説明するには、以下のパラメータのいずれかを指定してDescribeDBInstanceAutomatedBackupsアクションDbiResourceIdを呼び出します。

復元

自動バックアップから DB インスタンスを復元する方法については、「特定の時点への DB インスタンスの復元」を参照してください。

保持コスト

保持されている自動バックアップのコストは、関連付けられているシステムスナップショットの合計ストレージ容量のコストです。トランザクションログまたはインスタンスメタデータには追加料金はかかりません。バックアップのその他の料金ルールはすべて復元可能なインスタンスに適用されます。

例えば、実行中のインスタンスの割り当て済みストレージの合計が 100 GB であるとします。また、保持されている自動バックアップに関連付けられた手動スナップショットが 50 GB、システムスナップショットが 75 GB であるとします。この場合、25 GB の追加バックアップストレージについてのみ請求されます。(50 GB + 75 GB) - 100 GB = 25 GB。

制限事項

保持されている自動バックアップには､次の制限が適用されます｡

• 1 つの AWS リージョンで保持できる自動バックアップの最大数は 40 個です。これは、DB インスタンスのクォータには含まれません。40 の実行 DB インスタンスと追加の 40 の自動バックアップを同時に保持できます。

• 保持されている自動バックアップには、パラメータグループまたはオプショングループについての情報は含まれません。

• 削除したインスタンスは、削除時の保持期間内の時点に復元できます。

• 保持された自動バックアップは変更できません。これは、システムバックアップ、トランザクションログ、およびソースインスタンスを削除したときに存在した DB インスタンスプロパティで構成されているためです。

保持している自動バックアップの削除

保持された自動バックアップは、不要になったら削除できます。

コンソール

保持されている自動バックアップを削除するには

1. AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。

2. ナビゲーションペインで、[Automated backups (自動バックアップ)] を選択します。

3. Retainedタブで、削除する保持された自動バックアップを選択します。

4. [アクション] で、[削除] を選択します。

5. 確認ページで、「delete me」を入力し、[Delete (削除)] を選択します。

AWS CLI

次のオプションを指定して AWS CLI コマンド delete-db-instance-automated-backup を使用すると、保持されている自動バックアップを削除できます。

• --dbi-resource-id - ソース DB インスタンスのリソース識別子です。

  AWS CLI コマンド describe-db-instance-automated-backups を実行すると、保持された自動バックアップのソース DB インスタンスのリソース識別子を見つけることができます。

次の例では、ソース DB インスタンスのリソース識別子 db-123ABCEXAMPLE を持つ保持された自動バックアップを削除します。

Linux、macOS、Unix の場合:

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

Windows の場合:

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

RDS API

次のパラメータを指定して Amazon RDS API オペレーション DeleteDBInstanceAutomatedBackup を使用すると、保持されている自動バックアップを削除できます。

• DbiResourceId - ソース DB インスタンスのリソース識別子です。

  Amazon RDS API オペレーション DescribeDBInstanceAutomatedBackups を使用して、保持された自動バックアップのソース DB インスタンスのリソース識別子を見つけることができます。

自動バックアップの無効化

大量のデータをロードする場合など、特定の状況では、自動バックアップを一時的に無効にすることができます。

重要

自動バックアップは、無効にするとポイントインタイムリカバリも無効になるため、無効にしないことを強くお勧めします。DB インスタンスまたはマルチ AZ DB クラスターの自動バックアップを無効にすると、データベースの既存の自動バックアップがすべて削除されます。自動バックアップを無効にしてから再度有効にすると、自動バックアップを再度有効にした時点からリストアをスタートできます。

コンソール

自動バックアップをすぐに無効にするには

1. AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。

2. ナビゲーションペインで、[データベース] を選択し、変更する DB インスタンスまたはマルチ AZ DB クラスターを選択します。

3. Modify を選択します。

4. [バックアップ保持期間] で [0 日] を選択します。

5. [Continue] を選択します。

6. [Apply immediately] (すぐに適用) を選択します。

7. [DB インスタンスの変更] または [クラスターの変更] を選択して変更を保存し、自動バックアップを無効にします。

AWS CLI

自動バックアップをすぐに無効にするには、modify-db-instance または modify-db-cluster コマンドを使用して、バックアップ保持期間を 0 に設定し、--apply-immediately を指定します。

次の例では、マルチ AZ DB クラスターの自動バックアップをただちに無効にします。

Linux、macOS、Unix の場合:

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

Windows の場合:

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

変更が有効になるタイミングを知るには、バックアップ保持期間の値が 0 になり、mydbcluster ステータスが available になるまで、DB インスタンスに対して describe-db-instances (マルチ AZ DB クラスターの場合は describe-db-clusters) を呼び出します。

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

RDS API

自動バックアップをすぐに無効にするには、以下のパラメータを指定して、ModifyDBInstance または ModifyDBCluster オペレーションを呼び出します。

• DBInstanceIdentifier = mydbinstance+ または DBClusterIdentifier = mydbcluster-

• BackupRetentionPeriod = 0

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>

サポートされない MySQL ストレージエンジンを使用した自動バックアップ

MySQL DB エンジン、自動バックアップは InnoDB ストレージエンジンでのみサポートされています。これらの機能を他の MySQL ストレージエンジン (MyISAM など) で使用すると、バックアップからの復元中に動作の信頼性が失われる場合があります。具体的には、MyISAM などのストレージエンジンは信頼性の高いクラッシュリカバリをサポートしていないため、クラッシュ時にテーブルが破損する可能性があります。このため、InnoDB ストレージエンジンを使用することをお勧めします。

• 既存の MyISAM テーブルを InnoDB テーブルに変換する場合は、ALTER TABLE コマンド (ALTER TABLE table_name ENGINE=innodb, ALGORITHM=COPY; など) を使用できます。

• MyISAM の使用を選択した場合、REPAIR コマンドを使用して、クラッシュ後に破損したテーブルの修復を手動で試みることができます。詳細については、MySQL ドキュメントの「REPAIR TABLE 構文」を参照してください。ただし、MySQL ドキュメントで説明されているとおり、すべてのデータを復旧できない可能性が高くなります。

• 復元前に MyISAM テーブルのスナップショットを作成する場合は、次のステップに従います。

  1. MyISAM テーブルに対するすべてのアクティビティを停止します (つまり、すべてのセッションを閉じます)。

     SHOW FULL PROCESSLIST コマンドから返される各プロセスの mysql.rds_kill コマンドを呼び出すことによって、すべてのセッションを閉じます。

  2. 各 MyISAM テーブルをロックしてフラッシュします。例えば、次のコマンドは、myisam_table1 および myisam_table2 という名前の 2 つのテーブルをロックしてフラッシュします。

     mysql> FLUSH TABLES myisam_table, myisam_table2 WITH READ LOCK;

  3. DB インスタンスまたはマルチ AZ DB クラスターのスナップショットを作成します。スナップショットが完了したら、ロックを解除し、MyISAM テーブルでのアクティビティを再開します。次のコマンドを使用して、テーブルのロックを解除できます。

     mysql> UNLOCK TABLES;

  これらのステップでは、MyISAM によってメモリに保存されたデータがディスクに強制的にフラッシュされるため、DB スナップショットから復元する際のクリーンスタートを確実にできます。DB スナップショットの作成の詳細については、「シングル AZ DB インスタンスの DB スナップショットの作成」を参照してください。

サポートされない MariaDB ストレージエンジンを使用した自動バックアップ

MariaDB DB エンジン、自動バックアップは InnoDB ストレージエンジンでのみサポートされています。これらの機能を他の MariaDB ストレージエンジン (Aria など) で使用すると、バックアップからの復元中に動作の信頼性が失われる場合があります。Aria が MyISAM の代替となる耐クラッシュ性を備えたものであっても、テーブルはクラッシュ時に破損する可能性があります。このため、InnoDB ストレージエンジンを使用することをお勧めします。

• 既存の Aria テーブルを InnoDB テーブルに変換するには、ALTER TABLE コマンドを使用できます。例: ALTER TABLE table_name ENGINE=innodb, ALGORITHM=COPY;

• Aria の使用を選択した場合、REPAIR TABLE コマンドを使用して、クラッシュ後に破損したテーブルの修復を手動で試みることができます。詳細については、http://mariadb.com/kb/en/mariadb/repair-table/ を参照してください。

• 復元前に Aria テーブルのスナップショットを作成する場合は、次のステップに従います。

  1. Aria テーブルに対するすべてのアクティビティを停止します (つまり、すべてのセッションを閉じます)。

  2. 各 Aria テーブルをロックしてフラッシュします。

  3. DB インスタンスまたはマルチ AZ DB クラスターのスナップショットを作成します。スナップショットが完了したら、ロックを解除し、Aria テーブルでのアクティビティを再開します。これらのステップでは、Aria のメモリに保存されたデータがディスクに強制的にフラッシュされるため、DB スナップショットから復元する際に確実にクリーンスタートできます。