バックアップの使用 - Amazon Relational Database Service
バックアップストレージバックアップウィンドウバックアップの保存期間自動バックアップの有効化自動バックアップの保持保持している自動バックアップの削除自動バックアップの無効化AWS Backup を使用する サポートされていない MySQL ストレージエンジンサポートされていない MariaDB ストレージエンジン

バックアップの使用

Amazon RDS は、DB インスタンスのバックアップ期間中に、DB インスタンスまたはマルチ AZ DB クラスターの自動バックアップを作成して保存します。RDS は DB インスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、DB インスタンス全体をバックアップします。RDS は、指定したバックアップ保持期間に従って DB インスタンスの自動バックアップを保存します。必要に応じて、バックアップ保持期間内の任意の時点に DB インスタンスを回復できます。

自動バックアップは次のルールに従います。

  • 自動バックアップを行うには、DB インスタンスが available 状態になっている必要があります。DB インスタンスが storage_full など、available 以外の状態にある間は、自動バックアップは行われません。

  • DB スナップショットのコピーが同じデータベースの同じ AWS リージョン で実行している間は、自動バックアップは行われません。

DB スナップショットを作成することにより、手動で DB インスタンスをバックアップすることもできます。DB スナップショットの手動作成について詳しくは、「DB スナップショットの作成」を参照してください。

DB インスタンスの最初のスナップショットには、データベース全体のデータが含まれます。同じ DB インスタンスの後続のスナップショットは増分です。つまり、直近のスナップショットの保存後に変更されたデータのみが含まれます。

自動および手動 DB スナップショットのコピー、および手動 DB スナップショットの共有を行うことができます。DB スナップショットのコピーに関する詳細は、「DB スナップショットのコピー」を参照してください。DB スナップショットの共有に関する詳細は、「DB スナップショットの共有」を参照してください。

バックアップストレージ

各 AWS リージョン の Amazon RDS バックアップストレージは、そのリージョンの自動バックアップと手動 DB スナップショットで構成されています。バックアップストレージの合計容量は、そのリージョンのすべてのバックアップに対するストレージの合計と等しくなります。DB スナップショットを他のリージョンに移動すると、移動先リージョンのバックアップストレージは増加します。バックアップは Amazon S3 に保存されます。

バックアップストレージコストの詳細については、「Amazon RDS の料金」を参照してください。

DB インスタンスの削除時に自動バックアップを保持することを選択した場合、自動バックアップは全保持期間にわたって保存されます。DB インスタンスの削除時に、[Retain automated backups (自動バックアップの保持)] を選択しない場合、すべての自動バックアップは DB インスタンスと一緒に削除されます。削除後は、自動バックアップを復旧することはできません。Amazon RDS によって DB インスタンスの削除前に最終的な DB スナップショットが作成されるように選択した場合、そのスナップショットを使用して DB インスタンスを復元できます。オプションで、以前に作成した手動スナップショットを使用できます。手動スナップショットは削除されません。リージョンあたり最大 100 個の手動スナップショットを作成することができます。

バックアップウィンドウ

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

自動バックアップウィンドウ中、バックアッププロセスのスタート時にストレージ I/O が一時中断することがあります (通常は数秒間)。マルチ AZ 配置のバックアップ中は、レイテンシーが数分間高くなることがあります。MariaDB、MySQL、Oracle、PostgreSQL の場合、バックアップはスタンバイから取られるため、マルチ AZ 配置のバックアップ中、プライマリの I/O アクティビティは中断しません。SQL Server の場合、バックアップはプライマリから取られるため、シングル AZ 配置とマルチ AZ 配置のバックアップ中に 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
中国 (北京) 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状態にあった時間は含まれません。

重要

バックアップ保持期間を 0 から 0 以外の値、または 0 以外の値から 0 に変更すると、停止します。これは、シングル AZ とマルチ AZ DB インスタンスの両方に適用されます。

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

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 の 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 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 インスタンスプロパティも含まれます。

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

MySQL、MariaDB、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 コマンド 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

次のパラメータを指定して 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 インスタンスの変更] または [クラスターの変更] を選択して変更を保存し、自動バックアップを無効にします。

自動バックアップをすぐに無効にするには、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

自動バックアップをすぐに無効にするには、以下のパラメータを指定して、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>

自動バックアップの管理に AWS Backup を使用する

AWS Backup はフルマネージド型のバックアップサービスであり、クラウド内およびオンプレミスの AWS のサービス間でデータのバックアップを簡単に一元化および自動化できます。AWS Backup で Amazon RDS データベースのバックアップを管理できます。

AWS Backup でバックアップを有効にするには、リソースタグを使用して、データベースをバックアップ計画に関連付けます。詳細については、「タグを使用した AWS Backup でのバックアップの有効化」を参照してください。

注記

AWS Backup によって管理されるバックアップは手動 DB スナップショットと見なされますが、RDS の DB スナップショットクォータにはカウントされません。AWS Backup で作成されたバックアップの名前は awsbackup:backup-job-number で終わります。

AWS Backup の詳細については、AWS Backup デベロッパーガイドを参照してください。

AWS Backup によって管理されているバックアップを表示するには

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

  2. ナビゲーションペインで、[Snapshots] を選択します。

  3. [バックアップサービス] タブを選択します。

    AWS Backup バックアップは、[バックアップサービスのスナップショット] の下に一覧表示されます。

サポートされない 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 スナップショットの作成の詳細については、「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 スナップショットから復元する際に確実にクリーンスタートできます。