

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# リソースタイプ別のバックアップの作成
<a name="creating-a-backup"></a>

を使用すると AWS Backup、バックアッププランを使用して自動的にバックアップを作成することも、オンデマンドバックアップを開始して手動でバックアップを作成することもできます。

## 自動バックアップの作成
<a name="creating-automatic-backups"></a>

バックアッププランによって自動的にバックアップが作成される場合は、バックアッププランで定義されたライフサイクル設定を使用して設定されます。これらは、バックアップ計画で指定されたバックアップボールトに編成されます。また、バックアッププランに一覧表示されているタグも割り当てられます。バックアッププランの詳細については、「[バックアッププラン](about-backup-plans.md)」を参照してください。

## オンデマンドバックアップの作成
<a name="creating-on-demand-backups"></a>

オンデマンドバックアップを作成する場合は、作成するバックアップ用にこれらの設定を構成できます。自動または手動でバックアップが作成される場合、バックアップ*ジョブ*が開始されます。オンデマンドバックアップの作成方法については、「[を使用したオンデマンドバックアップの作成 AWS Backup](recov-point-create-on-demand-backup.md)」を参照してください。

注: オンデマンドバックアップではバックアップジョブが作成されます。バックアップジョブは 1 時間以内に (または指定した場合) `Running` 状態で移行します。バックアッププランに定義されている、スケジュールされた時刻以外の時間にバックアップを作成する場合は、オンデマンドバックアップを選択できます。オンデマンドバックアップは、例えばバックアップや機能をテストするためにいつでも使用できます。

[オンデマンドバックアップ](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-on-demand-backup.html)は、[ポイントインタイムリストア (PITR)](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html) では使用できません。オンデマンドバックアップはリソースをバックアップ作成時の状態で保持するのに対し、PITR は[継続的バックアップ](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html#point-in-time-recovery-working-with)を使用して一定期間にわたる変更を記録するためです。

## バックアップジョブのステータス
<a name="backup-job-statuses"></a>

各バックアップジョブには、一意の ID があります。例えば、`D48D8717-0C9D-72DF-1F56-14E703BF2345`。

バックアップジョブのステータスは、 AWS Backup バックアップコンソールの [**ジョブ**] ページで確認できます。バックアップジョブのステータスには、`CREATED`、`PENDING`、`RUNNING`、`ABORTING`、`ABORTED`、`COMPLETED`、`FAILED`、`EXPIRED`、および `PARTIAL` があります。

## 増分バックアップ
<a name="incremental-backup-works"></a>

多くの リソースは、 による増分バックアップをサポートしています AWS Backup。すべての一覧は、「[リソース別の機能の可用性](backup-feature-availability.md#features-by-resource) 表」の増分バックアップセクションにあります。

最初の (フル) バックアップの後の各バックアップは増分です (つまり、以前のバックアップからの変更のみをキャプチャします）。 で作成されたすべてのバックアップは、完全な復元を可能にするために必要な参照データ AWS Backup を保持します。これは、元の (フル) バックアップがライフサイクルの期限に達して削除された場合にも当てはまります。

例えば、3 日間のライフサイクルポリシーにより、1 日目 (フル) バックアップが削除された場合、2 日目と 3 日目のバックアップを使用してフル復元を実行できます。 AWS Backup は、それを有効にするため、1 日目の必要な参照データを保持します。

**増分バックアップとリージョン**

によって完全に管理されているリソースのバックアップは、バックアップが作成されたボールトに以前のバックアップ (増分またはフル) が含まれている場合にのみ増分 AWS Backup できます。同じ*リージョン*内のボールトに以前のバックアップがある限り、他のリソースタイプ ( によって完全に管理されていない AWS Backup) に増分バックアップを含めることができます。

## ソースリソースへのアクセス
<a name="source-resource-statuses"></a>

AWS Backup では、ソースリソースにアクセスしてバックアップする必要があります。例えば、次のようになります。
+ Amazon EC2 インスタンスをバックアップするには、インスタンスが `running` または `stopped` の状態であってもかまいませんが、`terminated` の状態にはなりません。これは、 `running`または `stopped`インスタンスは と通信できますが AWS Backup、 `terminated`インスタンスは通信できないためです。
+ 仮想マシンをバックアップするには、ハイパーバイザーのバックアップゲートウェイステータスが `ONLINE` である必要があります。詳細については、「[ハイパーバイザーステータスの理解](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-hypervisors.html#understand-hypervisor-status)」を参照してください。
+ Amazon RDS データベース、Amazon Aurora、または Amazon DocumentDB クラスターをバックアップするには、それらのリソースのステータスが `AVAILABLE` である必要があります。
+ Amazon Elastic File System (Amazon EFS) をバックアップするには、ステータスが `AVAILABLE` である必要があります。
+ Amazon FSx ファイルシステムをバックアップするには、ステータスが `AVAILABLE` である必要があります。ステータスが `UPDATING` の場合、バックアップリクエストはファイルシステムが `AVAILABLE` になるまでキューに入れられます。

  FSx for ONTAP は、DP (データ保護) ボリューム、LS (ロード共有) ボリューム、フルボリューム、ファイルシステム上のフルボリュームなど、特定のボリュームタイプのバックアップをサポートしていません。詳細については、「[FSx for ONTAP のバックアップの使用](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/using-backups.html)」を参照してください。

AWS Backup は、ソースリソースの状態に関係なく、ライフサイクルポリシーに従って以前に作成されたバックアップを保持します。

**Topics**
+ [自動バックアップの作成](#creating-automatic-backups)
+ [オンデマンドバックアップの作成](#creating-on-demand-backups)
+ [バックアップジョブのステータス](#backup-job-statuses)
+ [増分バックアップ](#incremental-backup-works)
+ [ソースリソースへのアクセス](#source-resource-statuses)
+ [CloudFormation スタックバックアップ](applicationstackbackups.md)
+ [Amazon Aurora DSQL バックアップ](backup-aurora.md)
+ [アドバンスト DynamoDB バックアップ](advanced-ddb-backup.md)
+ [Amazon EBS と AWS Backup](multi-volume-crash-consistent.md)
+ [Amazon Relational Database Service バックアップ](rds-backup.md)
+ [Amazon Redshift バックアップ](redshift-backups.md)
+ [Amazon Redshift Serverless バックアップ](redshift-serverless-backups.md)
+ [Amazon EKS backups](eks-backups.md)
+ [Amazon EC2 での SAP HANA のバックアップ](backup-saphana.md)
+ [Amazon S3 バックアップ](s3-backups.md)
+ [Amazon Timestream バックアップ](timestream-backup.md)
+ [仮想マシンのバックアップ](vm-backups.md)
+ [Windows VSS バックアップの作成](windows-backups.md)

# CloudFormation スタックバックアップ
<a name="applicationstackbackups"></a>

CloudFormation スタックは、単一のユニットとしてバックアップできる複数のステートフルおよびステートレスのリソースで構成されています。つまり、スタックをバックアップし、その中のリソースを復元することで、複数のリソースを含むアプリケーションをバックアップおよび復元できます。スタック内のすべてのリソースは、スタックの CloudFormation テンプレートで定義されます。

CloudFormation スタックがバックアップされると、CloudFormation テンプレートとスタック AWS Backup で がサポートする追加のリソースごとに復旧ポイントが作成されます。これらの復旧ポイントは、**複合**と呼ばれる包括的な復旧ポイントにまとめられます。

この複合復旧ポイントは復元できませんが、ネストされた復旧ポイントは復元できます。コンソールまたは AWS CLIを使用して、複合バックアップ内の 1 つのネストされたバックアップからすべてのネストされたバックアップまで復元できます。

## CloudFormation アプリケーションスタックの用語
<a name="appstackterminology"></a>
+ **複合復旧ポイント**: ネストされた復旧ポイントやその他のメタデータをグループ化するために使用される復旧ポイントです。
+ **ネストされた復旧ポイント**: CloudFormation スタックの一部であり、複合復旧ポイントの一部としてバックアップされるリソースの復旧ポイントです。ネストされた復旧ポイントは、それぞれ、1 つの複合復旧ポイントのスタックに属します。
+ **複合ジョブ**: CloudFormation スタックのバックアップジョブ、コピージョブ、または復元ジョブであって、スタック内の個々のリソースに対して他のバックアップジョブをトリガーできるものです。
+ **ネストされたジョブ**: CloudFormation スタック内のリソースのバックアップ、コピー、または復元ジョブ。

## CloudFormation スタックのバックアップジョブ
<a name="howtobackupcfn"></a>

バックアップ作成のプロセスは、バックアップジョブと呼ばれます。CloudFormation スタックのバックアップジョブには[ステータス](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#backup-job-statuses)があります。バックアップジョブが終了すると、ステータスは `Completed` になります。これは [CloudFormation 復旧ポイント](#cfnrecoverypoints) (バックアップ) が作成されたことを意味します。

CloudFormation スタックは、コンソールを使用してバックアップすることも、プログラムでバックアップすることもできます。CloudFormation スタックを含むリソースをバックアップするには、この「**AWS Backup デベロッパーガイド」で別途記載されている「[バックアップの作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html)」を参照してください。

CloudFormation スタックは API コマンド `StartBackupJob` を使用してバックアップできます。ドキュメントとコンソールは、複合復旧ポイントとネストされた復旧ポイントを指していることに注意してください。API 言語では「親復旧ポイントと子復旧ポイント」という用語が同じ文脈上の関係で使用されています。

CloudFormation スタックには、[CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)によって示されるすべての AWS リソースが含まれています。テンプレートには AWS Backupによってまだサポートされていないリソースが含まれている場合があることに注意してください。テンプレートに AWS サポートされているリソースとサポートされていないリソースの組み合わせが含まれている場合、 AWS Backup は引き続きテンプレートを複合スタックにバックアップしますが、Backup は Backup がサポートするサービスの復旧ポイントのみを作成します。(コンソール設定でサービスを [有効] に切り替えて) 特定のサービスにオプトインしていない場合でも、CloudFormation テンプレートに含まれるすべてのリソースタイプがバックアップに含まれます。

## CloudFormation 復旧ポイント
<a name="cfnrecoverypoints"></a>

### 復旧ポイントのステータス
<a name="cfnrecoverypointstatus"></a>

スタックのバックアップジョブが終了すると (ジョブステータスが `Completed` になると)、スタックのバックアップの作成が完了となります。このバックアップは複合復旧ポイントとも呼ばれます。複合復旧ポイントには、`Completed`、`Failed`、`Partial` のいずれかのステータスがあります。バックアップジョブに一定のステータスがありますが、復旧ポイント (バックアップとも呼ばれます) にも別個のステータスがあることに注意してください。

完了したバックアップジョブとは、スタック全体と 内のリソースが によって保護されていることを意味します AWS Backup。失敗ステータスは、バックアップジョブが失敗したことを示します。失敗の原因となった問題が修正されたら、バックアップを再度作成する必要があります。

`Partial` ステータスは、スタック内のすべてのリソースがバックアップされたわけではないことを意味します。これは、CloudFormation テンプレートに現在サポートされていないリソースが含まれている場合や AWS Backup、スタック内のリソース (ネストされたリソース) に属する 1 つ以上のバックアップジョブのステータスが 以外の場合に発生する可能性があります`Completed`。`Completed` 以外のステータスになったリソースがあれば、オンデマンドバックアップを手動で作成して、このリソースを再実行できます。スタックのステータスが `Completed` になるべきところが、`Partial` として表示されている場合は、上記のどの条件がスタックに当てはまるかを確認してください。

複合復旧ポイント内のネストされたリソースのそれぞれに、個別の復旧ポイントがあり、それぞれに独自のステータス (`Completed` または `Failed`) があります。ネストされた復旧ポイントで、ステータスが `Completed` のものは、復元できます。

### 復旧ポイントを管理する
<a name="cfnmanagerecoverypoints"></a>

複合復旧ポイント (バックアップ) はコピーでき、ネストされた復旧ポイントはコピー、削除、関連付け解除、または復元ができます。ネストされたバックアップを含む複合復旧ポイントは削除できません。複合復旧ポイント内の、ネストされた復旧ポイントを削除した後、または関連付けを解除した後は、複合復旧ポイントを手動で削除することも、バックアッププランのライフサイクルによって削除されるまでそのままにしておくこともできます。

### 復旧ポイントを削除する
<a name="cfndeleterecoverypoint"></a>

復旧ポイントは、 AWS Backup コンソールまたは を使用して削除できます AWS CLI。

 AWS Backup コンソールを使用して復旧ポイントを削除するには、次の手順を実行します。

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションで、**[保護されたリソース]** をクリックします。テキストボックスに [`CloudFormation`] と入力して、CloudFormation スタックのみが表示されるようにします。

1. 複合復旧ポイントは [復旧ポイント] ペインに表示されます。各復旧ポイント ID の左側にある [プラス記号 (\$1)] をクリックすると各複合復旧ポイントが展開され、複合に含まれるネストされた復旧ポイントのすべてが表示されます。任意の復旧ポイントの左側にあるチェックボックスをオンにすると、削除する復旧ポイントの選択にその復旧ポイントを含めることができます。

1. **[削除]** ボタンをクリックします。

コンソールを使用して 1 つ以上の複合復旧ポイントを削除すると、警告ボックスが表示されます。この警告ボックスでは、複合スタック内のネストされた復旧ポイントを含め、複合復旧ポイントを削除する意図の確認を求められます。

API を使用して復旧ポイントを削除するには、コマンド `DeleteRecoveryPoint` を使用します。

で API を使用する場合は AWS Command Line Interface 、複合ポイントを削除する前に、ネストされたすべての復旧ポイントを削除する必要があります。ネストされた復旧ポイントがまだ含まれている複合スタックバックアップ (復旧ポイント) を削除するための API リクエストを送信すると、リクエストはエラーを返します。

### ネストされた復旧ポイントと複合復旧ポイントの関連付けを解除する
<a name="cfndisassociaterecoverypoints"></a>

ネストされた復旧ポイントと複合復旧ポイントの関連付けを解除できます (例えば、ネストされた復旧ポイントをそのままにしておき、複合復旧ポイントを削除する場合など)。両方の復旧ポイントはそのまま残りますが、接続は解除されます。つまり、ネストされた復旧ポイントとの関連付けが解除されると、複合復旧ポイントで実行された操作は、ネストされた復旧ポイントには適用されなくなります。

コンソールを使用して復旧ポイントの関連付けを解除することも、API `DisassociateRecoveryPointFromParent` を呼び出すこともできます。[API 呼び出しでは、複合復旧ポイントを指すのに「親」という用語が使用されることに注意してください。]

### 復旧ポイントをコピーする
<a name="cfncopyrecoverypoint"></a>

複合復旧ポイントをコピーできます。また、リソースが[クロスアカウントコピーやクロスリージョンコピー](backup-feature-availability.md#features-by-resource)をサポートしている場合には、ネストされた復旧ポイントをコピーすることもできます。

 AWS Backup コンソールを使用して復旧ポイントをコピーするには:

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションで、**[保護されたリソース]** をクリックします。テキストボックスに [`CloudFormation`] と入力して、CloudFormation スタックのみが表示されるようにします。

1. 複合復旧ポイントは [復旧ポイント] ペインに表示されます。各復旧ポイント ID の左側にある [プラス記号 (\$1)] をクリックすると各複合復旧ポイントが展開され、複合に含まれるネストされた復旧ポイントのすべてが表示されます。任意の復旧ポイントの左側にある [放射状の円] ボタンをクリックすると、その復旧ポイントをコピーできます。

1. 選択したら、ペインの右上隅にある **[コピー]** ボタンをクリックします。

複合復旧ポイントをコピーしても、コピー機能をサポートしないネストされた復旧ポイントは、コピーされたスタックには含まれません。複合復旧ポイントのステータスは `Partial` になります。

## よくある質問
<a name="cfnfaq"></a>

1. *「アプリケーションバックアップには何が含まれていますか?」*

   CloudFormation を使用して定義されたアプリケーションの各バックアップの一部として、テンプレート、テンプレート内の各パラメータの処理された値、および でサポートされているネストされたリソース AWS Backup がバックアップされます。ネストされたリソースは、CloudFormation スタックの一部ではない個々のリソースをバックアップするのと同じ方法でバックアップされます。`no-echo` と表示されたパラメータの値はバックアップされないことに注意してください。

   

1. *「ネストされた CloudFormation スタックがあるスタックをバックアップできますか?*」

   はい。ネストされたスタックを含む CloudFormation スタックをバックアップに含めることができます。

   

1. *「`Partial` ステータスはバックアップの作成に失敗したことを意味しますか?」*

   いいえ。一部のステータスでは、一部の復旧ポイントがバックアップされたものの、一部はバックアップされなかったことが示されます。`Completed` バックアップ結果を期待していたかどうかを確認するには、次の 3 つの条件があります。

   1. お使いの CloudFormation スタックには、現在 AWS Backupによってサポートされていないリソースが含まれていますか? サポートされているリソースのリストについては、「 デベロッパーガイド[」の「サポートされている AWS リソースとサードパーティーアプリケーション](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#supported-resources)」を参照してください。

   1. スタック内のリソースに属する 1 つ以上のバックアップジョブが成功しなかったため、ジョブを再実行する必要があります。

   1. ネストされた復旧ポイントが削除されたか、複合復旧ポイントとの関連付けが解除されました。

   

1. *「CloudFormation スタックのバックアップからリソースを除外する方法を教えてください。」*

   CloudFormation スタックをバックアップする場合、リソースをバックアップの一部から除外できます。コンソールでは、[バックアッププランの作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html)と[バックアッププランの更新](https://docs.aws.amazon.com/aws-backup/latest/devguide/updating-a-backup-plan.html)のプロセス中に、[リソースを割り当てる](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html)ステップがあります。このステップには、**リソース選択**セクションがあります。**[特定のリソースタイプを含める]** を選択したうえで、バックアップするリソースとして CloudFormation を含めた場合は、**選択したリソースタイプから特定のリソース ID を除外**できます。タグを使用して、スタック内のリソースを除外することもできます。

   CLI を使用すると、次の操作ができます。
   + `NotResources` バックアッププランで、CloudFormation スタックから特定のリソースを除外する。
   + `StringNotLike` タグを使用して項目を除外する。

   

1. *「ネストされたリソースではどのような種類のバックアップがサポートされていますか?」*

   ネストされたリソースのバックアップは、これらのリソース AWS Backup に対して でサポートされているバックアップの種類に応じて、フルバックアップまたは増分バックアップのいずれかになります。詳細については、「[増分バックアップの仕組み](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#how-incremental-backup-works)」を参照してください。ただし、PITR (ポイントインタイムリカバリ) は Amazon S3 および Amazon RDS のネストされたリソースでは[サポートされていない](backup-feature-availability.md#features-by-resource)ことに注意してください。

   

1. *「CloudFormation スタックの一部である変更セットはバックアップされますか?」*

   いいえ。変更セットは、CloudFormation スタックバックアップの一部としてバックアップされません。

   

1. * CloudFormation 「スタックのステータスはバックアップにどのように影響しますか?*」

   CloudFormation スタックのステータスはバックアップに影響を与える可能性があります。`COMPLETE` を含むステータス (`CREATE_COMPLETE`、`ROLLBACK_COMPLETE`、`UPDATE_COMPLETE`、`UPDATE_ROLLBACK_COMPLETE`、`IMPORT_COMPLETE`、または `IMPORT_ROLLBACK_COMPLETE` などのステータス) であるスタックはバックアップが可能です。

   新しいテンプレートのアップロードが失敗し、スタックが `ROLLBACK_COMPLETE` のステータスに移行した場合、新しいテンプレートはバックアップされますが、ネストされたリソースのバックアップはロールバックされたリソースに基づいて行われます。

   

1. *「アプリケーションスタックのライフサイクルは、他の復旧ポイントのライフサイクルとどう違うのですか?」*

   ネストされた復旧ポイントのライフサイクルは、その復旧ポイントが属するバックアッププランによって決まります。複合復旧ポイントは、ネストされた復旧ポイントのすべてのライフサイクルが最も長いものによって決まります。複合復旧ポイント内にあるネストされた復旧ポイントのうち最後に残っているものが削除されるか、関連付けが解除されると、複合復旧ポイントも削除されます。

   

1. *「CloudFormation のタグはどのようにしてリカバリーポイントにコピーされるのですか?」*

   はい。これらのタグは、ネストされた復旧ポイントのそれぞれにコピーされます。

1. *「複合復旧ポイントとネストされた復旧ポイント (バックアップ) を削除する順序はありますか?」*

   はい。一部のバックアップは、他のバックアップを削除する前に削除する必要があります。ネストされた復旧ポイントを含む複合バックアップは、複合バックアップ内の復旧ポイントのすべてが削除されるまで削除できません。複合復旧ポイントに、ネストされた復旧ポイントが含まれなくなったら、手動で削除できます。それ以外の場合は、バックアッププランのライフサイクルに従って削除されます。

   

## スタック内のアプリケーションを復元する
<a name="restore-app-stack"></a>

ネストされた復旧ポイントの復元に関する詳細については、「[アプリケーションスタックのバックアップを復元する方法](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-application-stacks.html)」を参照してください。

# Amazon Aurora DSQL バックアップ
<a name="backup-aurora"></a>

を使用して AWS Backup 、Amazon Aurora DSQL シングルリージョンおよびマルチリージョンクラスターのバックアップを作成できます。Amazon Aurora DSQL クラスターのバックアップは常にフルバックアップです。

Amazon Aurora DSQL クラスターのバックアップ作成では、標準のバックアップ作成プロセスを使用します。詳細については次を参照してください:
+ [を使用したオンデマンドバックアップの作成 AWS Backup](recov-point-create-on-demand-backup.md)
+ [バックアッププランの作成](creating-a-backup-plan.md)

 AWS Backup を使用して Amazon Aurora DSQL クラスターのバックアップを作成するには、Aurora DSQL の保護を有効にする必要があります。詳細については、「[サービスオプトイン](getting-started.md#service-opt-in)」を参照してください。

マルチリージョンクラスターをバックアップする場合は、次の点を考慮してください。
+ マルチリージョンクラスターのバックアップでは、クラスター内のリージョンごとに個別のバックアップが必要です。1 つのリージョンのバックアップでは、マルチリージョンクラスター内のすべてのリージョン用の復旧ポイントが作成されません。
+ ベストプラクティスとして、あるリージョンに復旧ポイントを作成し、別の関連リージョンにコピー AWS Backup することをお勧めします。[マルチリージョン復元](restore-auroradsql.md#restore-auroradsql-multiregion)の場合、サポートされている 1 つのリージョンに復旧ポイント、および同じリージョントリプレット内の別のリージョンにその復旧ポイントのコピーが必要です。

  次のサポートされているトリプレットを使用できます。リージョンが複数ある場合は、同じグループで 3 つを選択します。
  + 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)
  + 欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)
  + アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)

AWS Backup では、バックアップコピールールをバックアッププランに追加することをお勧めします。バックアッププランにコピールールを追加しない場合は、復元を実行するために必要なリージョンにバックアップを手動でコピーする必要があります。これにより、目標復旧時間 (RTO) 時間が長くなります。

Aurora DSQL 復旧ポイント (バックアップ) の復元の詳細については、「[Amazon Aurora DSQL の復元](restore-auroradsql.md)」を参照してください。

# アドバンスト DynamoDB バックアップ
<a name="advanced-ddb-backup"></a>

AWS Backup は、Amazon DynamoDB データ保護のニーズに応じて、追加の高度な機能をサポートしています。

2021 年 11 月 AWS Backup 以降に の使用を開始したお客様は、高度な DynamoDB バックアップ機能がデフォルトで有効になっています。具体的には、2021 年 11 月 21 日より前にバックアップボールトを作成していないお客様には、高度な DynamoDB バックアップ機能がデフォルトで有効になっています。

既存の AWS Backup お客様が DynamoDB の高度な機能を有効にするのがベストプラクティスです。高度な機能を有効にした後、ウォームバックアップストレージの価格に違いはありません。バックアップをコールドストレージに移動することで費用を削減し、コスト配分タグを使用することでコストを最適化できる可能性があります。また、 AWS Backupのクロスリージョンコピーとクロスアカウントコピーとセキュリティ機能の利用を開始することもできます。

**Topics**
+ [高度な DDB バックアップの利点](#advanced-ddb-backup-benefits)
+ [Advanced DynamoDB バックアップに関する考慮事項](#advanced-ddb-considerations)
+ [コンソールを使用した高度な DynamoDB バックアップの有効化](#advanced-ddb-backup-enable-console)
+ [高度な DynamoDB バックアップをプログラムで有効にする](#advanced-ddb-backup-enable-cli)
+ [高度な DynamoDB バックアップを編集する](#advanced-ddb-backup-edit)
+ [高度な DynamoDB バックアップを復元する](#advanced-ddb-backup-restore)
+ [高度な DynamoDB バックアップを削除する](#advanced-ddb-backup-delete)
+ [高度な DynamoDB バックアップを有効にする場合のフル AWS Backup 管理のその他の利点](#advanced-ddb-backup-other-benefits)

## 高度な DDB バックアップの利点
<a name="advanced-ddb-backup-benefits"></a>

で AWS Backupの高度な機能を有効にしたら AWS リージョン、作成したすべての DynamoDB テーブルの新規バックアップについて、次の機能をロック解除します。
+ コスト削減と最適化:
  + 「[コールドストレージへのバックアップの階層化](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_Lifecycle.html)」でストレージコストを削減する
  + [コストエクスプローラーで使用するためのコスト配分タグ付け](https://docs.aws.amazon.com/aws-backup/latest/devguide/metering-and-billing.html#cost-allocation-tags)
+ 追加のコピーオプション:
  + [リージョン間の COPY](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html)
  + [アカウント間のコピー](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html#prereq-cab)
+ のセキュリティ
  + バックアップはソース DynamoDB テーブルからタグを継承し、これらのタグを使用してパーミッション、[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を設定します。

## Advanced DynamoDB バックアップに関する考慮事項
<a name="advanced-ddb-considerations"></a>

**オプトイン**

高度な DDB リソースのバックアップを含むバックアップは、バックアッププランやオンデマンドバックアップにより、またはバックアップポリシーを通じて作成できます。プランまたはオンデマンドで作成されたバックアップは、高度な DDB リソースのバックアップを許可するように、アカウントを自動的にオプトインします。

バックアップジョブがバックアップポリシーによって作成されている場合は、[バックアップコンソール](assigning-resources-console.md)または [CLI](assigning-resources-json.md) を通じて、高度な DynamoDB バックアップに手動でオプトインする必要があります。

**カスタムポリシーとロール**

 AWS Backupデフォルトのサービスロールの代わりにカスタムロールまたはポリシーを使用する場合は、カスタムロールに次のアクセス許可ポリシーを追加または使用 (または同等のアクセス許可を追加) する必要があります。
+ `AWSBackupServiceRolePolicyForBackup` は、高度な DynamoDB バックアップを実行します。
+ `AWSBackupServiceRolePolicyForRestores` は、高度な DynamoDB バックアップを復元します。

 AWS管理ポリシーの詳細とカスタマー管理ポリシーの例については、「」を参照してください[の管理ポリシー AWS Backup](security-iam-awsmanpol.md)。

## コンソールを使用した高度な DynamoDB バックアップの有効化
<a name="advanced-ddb-backup-enable-console"></a>

 AWS Backup または DynamoDB コンソールを使用して、DynamoDB バックアップの AWS Backup 高度な機能を有効にできます。

**AWS Backup コンソールから高度な DynamoDB バックアップ機能を有効にするには:**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションメニューから、[**設定**] を選択します。

1. **サポートされるサービス**セクションで、**DynamoDB** が [**Enabled (有効)]** であることを確認します。

   そうでない場合は、[**オプトイン**] を選択し、 AWS Backup サポートサービスとして DynamoDB を有効にします。

1. [**DynamoDB バックアップの高度な機能**] セクションで、[**有効化**] を選択します。

1. **[Enable features]** (機能の有効化) を選択します。

DynamoDB コンソールを使用して AWS Backup 高度な機能を有効にする方法については、*「Amazon DynamoDB ユーザーガイド*」の[AWS Backup 「機能の有効化](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/CreateBackupAWS.html#CreateBackupAWS_enabling)」を参照してください。

## 高度な DynamoDB バックアップをプログラムで有効にする
<a name="advanced-ddb-backup-enable-cli"></a>

(CLI) を使用して AWS Command Line Interface 、DynamoDB バックアップの AWS Backup 高度な機能を有効にすることもできます。DynamoDB の高度なバックアップは、次の値を両方とも `true` に設定した場合に有効にします。

**DynamoDB バックアップの AWS Backup 高度な機能をプログラムで有効にするには:**

1. 次のコマンドを使用して、DynamoDB の AWS Backup 高度な機能がすでに有効になっているかどうかを確認します。

   ```
   $ aws backup describe-region-settings
   ```

   もし `"DynamoDB":true` が `"ResourceTypeManagementPreference"` および `"ResourceTypeOptInPreference"` 両方の下にある場合、DynamoDB の高度なバックアップはすでに有効化しています。

   次の出力のように、`"DynamoDB":false` のインスタンスが少なくとも 1 つある場合は、まだ高度な DynamoDB バックアップを有効にしていないので、次のステップに進みます。

   ```
   {
     "ResourceTypeManagementPreference":{
       "DynamoDB":false,
       "EFS":true
     }
     "ResourceTypeOptInPreference":{
       "Aurora":true,
       "DocumentDB":false,
       "DynamoDB":false,
       "EBS":true,
       "EC2":true,
       "EFS":true,
       "FSx":true,
       "Neptune":false,
       "RDS":true,
       "Storage Gateway":true
     }
   }
   ```

1. 以下の [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UpdateRegionSettings.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UpdateRegionSettings.html) オペレーションを使用して、`"ResourceTypeManagementPreference"` および `"ResourceTypeOptInPreference"` の両方を `"DynamoDB":true` に設定します。

   ```
   aws backup update-region-settings \ 
                 --resource-type-opt-in-preference DynamoDB=true \
                 --resource-type-management-preference DynamoDB=true
   ```

## 高度な DynamoDB バックアップを編集する
<a name="advanced-ddb-backup-edit"></a>

 AWS Backup 高度な機能を有効にした後に DynamoDB バックアップを作成する場合、 AWS Backup を使用して次のことができます。
+ リージョン間のバックアップのコピー
+ アカウント間でバックアップをコピーする
+ がバックアップをコールドストレージに AWS Backup 階層化するタイミングを変更する
+ バックアップにタグを付ける

既存のバックアップでこれらの高度な機能を使用するには、「[バックアップの編集](https://docs.aws.amazon.com/aws-backup/latest/devguide/editing-a-backup.html)」を参照してください。

後で DynamoDB の AWS Backup 高度な機能を無効にした場合、高度な機能を有効にした期間中に作成した DynamoDB バックアップに対してこれらのオペレーションを引き続き実行できます。

## 高度な DynamoDB バックアップを復元する
<a name="advanced-ddb-backup-restore"></a>

 AWS Backup 高度な機能を有効にする前に取得した DynamoDB バックアップを復元するのと同じ方法で、 AWS Backup 高度な機能を有効にして取得した DynamoDB バックアップを復元できます。復元は、 AWS Backup または DynamoDB を使用して実行できます。

次のオプションを使用して、新しく復元されたテーブルの暗号化方法を指定できます。
+ 元のテーブルと同じリージョンで復元する場合、必要に応じて復元されたテーブルの暗号化キーを指定できます。暗号化キーを指定しない場合、 AWS Backup は元のテーブルを暗号化したのと同じキーを使用して、復元されたテーブルを自動的に暗号化します。
+ 元のテーブルとは異なるリージョンで復元する場合は、暗号化キーを指定する必要があります。

 を使用して復元するには AWS Backup、「」を参照してください[Amazon DynamoDB テーブルの復元](restoring-dynamodb.md)。

DynamoDB を使用して復元するには、*Amazon DynamoDB ユーザーガイド*の「[バックアップからの DynamoDB テーブルの復元](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Restore.Tutorial.html)」を参照してください。

## 高度な DynamoDB バックアップを削除する
<a name="advanced-ddb-backup-delete"></a>

DynamoDB のこれらの高度な機能を使用して作成されたバックアップを削除することはできません。バックアップを削除して AWS 環境全体にわたってグローバルな整合性を維持するには、 AWS Backup を使用する必要があります｡

DynamoDB バックアップを削除するには、[バックアップの削除](deleting-backups.md) を参照してください。

## 高度な DynamoDB バックアップを有効にする場合のフル AWS Backup 管理のその他の利点
<a name="advanced-ddb-backup-other-benefits"></a>

DynamoDB の AWS Backup 高度な機能を有効にすると、DynamoDB バックアップを完全に管理できます AWS Backup。そうすることで、次のような追加のメリットが得られます。

**暗号化**

AWS Backup は、送信先 AWS Backup ボールトの KMS キーを使用してバックアップを自動的に暗号化します。以前は、ソース DynamoDB テーブルと同じ暗号化方法を使用して暗号化されていました。これにより、データの保護に使用できる防御の数が増えます。詳細については「[でのバックアップの暗号化 AWS Backup](encryption.md)」を参照してください。

**Amazon リソースネーム (ARN)**

各バックアップ ARN のサービス名前空間は `awsbackup` です。以前は、サービスの名前空間は `dynamodb` でした。別の言い方をすれば、各 ARN の始まりが `arn:aws:dynamodb` から `arn:aws:backup` に変わります。「サービス認可リファレンス」で [AWS Backupの ARN](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsbackup.html#awsbackup-resources-for-iam-policies) について参照してください。**

この変更により、ユーザーまたはバックアップ管理者は、高度な機能を有効にした後に作成された DynamoDB バックアップに適用される `awsbackup` サービス名前空間を使用してバックアップのためにアクセスポリシーを作成できます。`awsbackup` サービス名前空間を使用して、 AWS Backupによって作成される他のバックアップにポリシーを適用することもできます。詳細については「[アクセスコントロール](access-control.md)」を参照してください。

**請求明細書の請求場所**

バックアップ (ストレージ、データ転送、復元、早期削除を含む) の料金は、 AWS 請求書の「バックアップ」の下に表示されます。以前は、請求額の「DynamoDB」の下に料金が表示されていました。

この変更により、 AWS Backup 請求を使用してバックアップコストを一元的にモニタリングできます。詳細については「[の計測、コスト、請求 AWS Backupメータリング、コスト、および請求](metering-and-billing.md)」を参照してください。

# Amazon EBS と AWS Backup
<a name="multi-volume-crash-consistent"></a>

Amazon EBS リソースのバックアッププロセスは、他のリソースタイプをバックアップする手順と似ています。
+ [オンデマンドバックアップを作成する](recov-point-create-on-demand-backup.md)
+ [スケジュールされたバックアップを作成する](creating-a-backup-plan.md)

以下のセクションで、リソース固有の情報を紹介します。

## コールドストレージ用の Amazon EBS アーカイブ階層
<a name="ebs-archive-tier"></a>

EBS は、バックアップのコールドストレージへの移行に対応するリソースの 1 つです。詳細については、「[ライフサイクルとストレージ階層](plan-options-and-configuration.md#backup-lifecycle)」を参照してください。

## Amazon EBS マルチボリュームのクラッシュコンシステントバックアップ
<a name="ebs-multi-volume"></a>

デフォルトでは、 は Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームのクラッシュコンシステントバックアップ AWS Backup を作成します。クラッシュの一貫性は、同じ Amazon EC2 インスタンスにアタッチされたすべての Amazon EBS ボリュームのスナップショットがまったく同じ瞬間に取得されることを意味します。アプリケーションの状態のクラッシュコンシステントを確保するために、インスタンスを停止したり、複数の Amazon EBS ボリューム間で調整する必要がなくなりました。

マルチボリュームのクラッシュコンシステントスナップショットはデフォルトの AWS Backup 機能であるため、この機能を使用するには別の操作を行う必要はありません。

EBS スナップショット復旧ポイントの作成に使用されるロールは、そのスナップショットに関連付けられます。この同じロールを使用して、そのロールによって作成された復旧ポイントを削除したり、その復旧ポイントをアーカイブ階層に移行したりする必要があります。

## Amazon EBS スナップショットロックと AWS Backup
<a name="ebs-snapshotlock"></a>

AWS Backup マネージド Amazon EBS スナップショットと、Amazon EBS スナップショットロックが適用された AWS Backup マネージド Amazon EC2 AMI に関連付けられたスナップショットは、スナップショットロック期間がバックアップライフサイクルを超える場合、復旧ポイントライフサイクルの一部として削除できない場合があります。この場合、復旧ポイントのステータスは `EXPIRED` になります。これらの復旧ポイントは、最初に Amazon EBS Snapshot Lock の解除を選択すると、[手動で削除](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html#deleting-backups-manually)できます。

## Amazon EBS リソースの復元
<a name="ebs-restore-link"></a>

Amazon EBS ボリュームを復元するには、「[Amazon EBS ボリュームの復元](restoring-ebs.md)」の手順に従います。

# Amazon Relational Database Service バックアップ
<a name="rds-backup"></a>

## Amazon RDS と AWS Backup
<a name="rds-backup-differences"></a>

Amazon RDS インスタンスとクラスターをバックアップするオプションを検討するときは、作成して使用するバックアップの種類を明確にすることが重要です。Amazon RDS を含むいくつかの AWS リソースは、独自のネイティブバックアップソリューションを提供します。

Amazon RDS には、[自動バックアップ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html)と[手動バックアップ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingManualBackups.html)を作成するオプションがあります。によって作成された復旧ポイントは AWS Backup 、バックアップタイプに応じて分類が異なります。
+ によって作成された**定期的なスナップショットは、**Amazon RDS の手動バックアップと見なされます。 AWS Backup これらは、バックアッププランのスケジュールに従って作成されたスナップショットベースのバックアップです。
+ によって作成された**継続的バックアップ** AWS Backup は、Amazon RDS の自動バックアップと見なされます。これにより、自動スナップショットとともにトランザクションログを維持することでpoint-in-time復元 (PITR) が可能になります。

手動バックアップと自動バックアップの保持動作とライフサイクル管理は Amazon RDS で異なるため、この違いは重要です。

 AWS Backup を使用して Amazon RDS インスタンスの[バックアップ (復旧ポイント) を作成する](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#create-backup-plan-console)場合、 AWS Backup は、Amazon RDS を使用して自動バックアップを作成したことがあるかどうかをチェックします。自動バックアップが存在する場合、 は増分スナップショットコピー AWS Backup を作成します (`copy-db-snapshot` オペレーション）。バックアップが存在しない場合、 はコピー (`create-db-snapshot` オペレーション) の代わりに、指定したインスタンスのスナップショット AWS Backup を作成します。

 AWS Backupいずれかのオペレーションによって作成された最初のスナップショットは、1 つの完全なスナップショットになります。これ以降のすべての*コピー*は、完全バックアップが存在する限り、増分バックアップになります。

クロスアカウントまたはクロスリージョンコピーを使用する場合、増分スナップショットコピージョブは、完全なスナップショットコピージョブよりも速く処理されます。新しいコピージョブが完了するまで以前のスナップショットコピーを保持しておくと、コピージョブの所要時間の短縮になる可能性があります。RDS データベースインスタンスからスナップショットをコピーする場合、以前のコピーを先に削除すると、(増分スナップショットコピーではなく) フルスナップショットコピーが作成されることに注意してください。コピーの最適化の詳細については、*「Amazon RDS ユーザーガイド*」の[「増分スナップショットコピー](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html#USER_CopySnapshot.Incremental)」を参照してください。

**重要**  
 AWS Backup バックアッププランが Amazon RDS インスタンスの複数の日次スナップショットを作成するようにスケジュールされており、それらのスケジュールされた[AWS Backup バックアップ開始ウィンドウ](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#plan-options-and-configuration)の 1 つが [Amazon RDS Backup ウィンドウ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupWindow)と一致すると、バックアップのデータ系統が非同一バックアップに分岐し、予期しない競合するバックアップを作成できます。これを防ぐには、 AWS Backup バックアッププランまたは Amazon RDS ウィンドウが時間と一致しないようにしてください。

### 考慮事項
<a name="rds-backup-considerations"></a>

RDS Custom for SQL Server および RDS Custom for Oracle は、現在、 AWS Backupによってサポートされていません。

AWS Backup は、RDS on Outposts のバックアップと復元をサポートしていません。

## Amazon RDS の継続的バックアップとポイントインタイムリストア
<a name="rds-backup-continuous"></a>

継続的バックアップには AWS Backup 、 を使用して Amazon RDS リソースの完全なバックアップを作成し、トランザクションログを介してすべての変更をキャプチャすることが含まれます。一定の時間間隔で取得された以前のスナップショットを選択する代わりに、復元する時点まで巻き戻すことで、詳細度を高めることができます。

詳細については、[「継続的バックアップ/ポイントインタイム復元でサポートされているサービス (PITR）](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html#point-in-time-recovery-supported-services)」および「[継続的バックアップ設定の管理](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html#point-in-time-recovery-managing)」を参照してください。

## Amazon RDS マルチアベイラビリティゾーンのバックアップ
<a name="rds-multiaz"></a>

AWS Backup は、1 つのプライマリデータベースインスタンスと 2 つの読み取り可能なスタンバイデータベースインスタンスを使用して、Amazon RDS for MySQL および for PostgreSQL マルチ AZ (アベイラビリティーゾーン) のデプロイオプションをバックアップし、サポートします。

マルチアベイラビリティーゾーンのバックアップは、以下のリージョンで利用可能です。アジアパシフィック (シドニー) リージョン、アジアパシフィック (東京) リージョン、欧州 (アイルランド) リージョン、米国東部 (オハイオ) リージョン、米国西部 (オレゴン) リージョン、欧州 (ストックホルム) リージョン、アジアパシフィック (シンガポール) リージョン、米国東部 (バージニア北部) リージョン、および欧州 (フランクフルト) リージョンです。

マルチ AZ 配置オプションは、書き込みトランザクションを最適化するものであり、読み込み容量の追加、書き込みトランザクションの待ち時間の短縮、(書き込みトランザクションの遅延の一貫性に影響する) ネットワークジッターからの耐障害性、および高い可用性と耐久性を必要とするワークロードに最適です。

マルチ AZ クラスターを作成するには、エンジンタイプとして MySQL または PostgreSQL のいずれかを選択できます。

 AWS Backup コンソールには、次の 3 つのデプロイオプションがあります。
+ **マルチ AZ DB クラスター:** 1 つのプライマリ DB インスタンスと 2 つの読み取り可能なスタンバイ DB インスタンスを含む DB クラスターを作成します。これらは、各 DB インスタンスは異なるアベイラビリティーゾーンにあります。サーバー対応ワークロードに高可用性とデータ冗長性を提供し、容量を増やします。
+ **マルチ AZ DB インスタンス:** プライマリ DB インスタンスとスタンバイ DB インスタンスが別個のアベイラビリティーゾーンに作成されます。これにより高い可用性とデータの冗長性が得られますが、スタンバイ DB インスタンスは読み取りワークロードの接続をサポートしていません。
+ **単一の DB インスタンス:** スタンバイ DB インスタンスのない単一の DB インスタンスを作成します。

**インスタンスとクラスターでのバックアップ動作**
+ [ポイントインタイムリカバリ](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html) (PITR) はインスタンスをサポートしていますが、クラスターはサポートしていません。
+ マルチ AZ DB クラスターのスナップショットのコピーはサポートされていません。
+ RDS 復旧ポイントの Amazon リソースネーム (ARN) は、インスタンスとクラスターのどちらが使用されているかによって異なります。

  RDS インスタンスの ARN: `arn:aws:rds:region: account:db:name`

  RDS マルチアベイラビリティクラスター:`arn:aws:rds:region:account:cluster:name`

詳細については、「**Amazon RDS ユーザーガイド」の「[マルチ AZ DB クラスターのデプロイ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)」を参照してください。

[マルチ AZ DB クラスタースナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateMultiAZDBClusterSnapshot.html)に関する詳細については、「Amazon RDS ユーザーガイド」を参照してください。

## Amazon Aurora グローバルデータベース
<a name="rds-aurora-global"></a>

AWS では、グローバルデータベースがデプロイされているすべてのリージョンでバックアップを維持することを推奨しています。

# Amazon Redshift バックアップ
<a name="redshift-backups"></a>

Amazon Redshift はフルマネージド型のスケーラブルなクラウドデータウェアハウスで、迅速、簡単、安全な分析により、インサイトを得るまでの時間を短縮します。を使用して AWS Backup 、変更不可能なバックアップ、個別のアクセスポリシー、バックアップジョブと復元ジョブの一元的な組織ガバナンスでデータウェアハウスを保護できます。

Amazon Redshift データウェアハウスは、ノードと呼ばれるコンピューティングリソースのコレクションであり、cluster. AWS Backup can と呼ばれるグループに編成され、これらのクラスターをバックアップできます。

[Amazon Redshift](https://docs.aws.amazon.com/redshift/index.html) の詳細については、「[Amazon Redshift 入門ガイド](https://docs.aws.amazon.com/redshift/latest/gsg/index.html)」、「[Amazon Redshift データベースデベロッパーガイド](https://docs.aws.amazon.com/redshift/latest/dg/index.html)」、および「[Amazon Redshift クラスター管理ガイド](https://docs.aws.amazon.com/redshift/latest/mgmt/index.html)」を参照してください。

## Amazon Redshift でプロビジョニングされたクラスターのバックアップ
<a name="backupredshift"></a>

Amazon Redshift クラスターは、 AWS Backup コンソールを使用するか、API または CLI を使用してプログラムで保護できます。これらのクラスターは、バックアッププランの一環として定期的なスケジュールでバックアップすることも、必要に応じてオンデマンドバックアップでバックアップすることもできます。

単一のテーブル (「項目レベルの復元」とも呼ばれます) またはクラスター全体を復元できます。テーブルは単独ではバックアップできないことに注意してください。クラスターをバックアップすると、テーブルはクラスターの一部としてバックアップされます。

 AWS Backup を使用すると、リソースを一元的に表示できますが、Amazon Redshift が唯一のリソースである場合は、Amazon Redshift の自動スナップショットスケジューラを引き続き使用できます。経由で管理することを選択した場合、Amazon Redshift を使用して手動スナップショット設定を引き続き管理することはできません AWS Backup。

Amazon Redshift クラスターは、 AWS Backup コンソールまたは を使用してバックアップできます AWS CLI。

 AWS Backup コンソールを使用して Amazon Redshift クラスターをバックアップするには、オンデマンドまたはバックアッププランの一部としての 2 つの方法があります。

### オンデマンド Amazon Redshift バックアップを作成する
<a name="ondemandredshiftbackups"></a>

詳細については、「[オンデマンドバックアップタイプ](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-on-demand-backup.html)の作成」ページを参照してください。

手動スナップショットを作成するには、Amazon Redshift リソースを含むバックアッププランを作成するときに、継続的バックアップチェックボックスをオフのままにします。

### バックアッププランで、スケジュールされた Amazon Redshift バックアップを作成する
<a name="scheduledredshiftbackups"></a>

保護されたリソースであれば、スケジュールされたバックアップに Amazon Redshift クラスターを含めることができます。Amazon Redshift クラスターの保護をオプトインするには:

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[保護されたリソース]** を選択します。

1. Amazon Redshift を **[オン]** に切り替えます。

1. Amazon Redshift クラスターを既存または新規のプランに含めるには、「[コンソールへのリソースの割り当て](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html#assigning-resources-console)」を参照してください。

**[バックアッププランを管理]** では、[バックアッププランを作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html)して、Amazon Redshift クラスターを含めるか、[既存のプランを更新](https://docs.aws.amazon.com/aws-backup/latest/devguide/updating-a-backup-plan.html)して Amazon Redshift クラスターを含めるかを選択できます。リソースタイプとして *Amazon Redshift* を追加する場合、**[すべての Redshift クラスター]** を選択して追加するか、バックアッププランに含めるクラスターの横にあるチェックボックスをオンします。

### プログラムによるバックアップ
<a name="redshiftbackupapi"></a>

JSON ドキュメントでバックアッププランを定義して、 AWS Backup コンソールまたは AWS CLIを使用して提供することもできます。プログラムで[バックアッププランを作成する方法については、「JSON ドキュメントと AWS Backup CLI を使用した](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#create-backup-plan-cli)バックアッププランの作成」を参照してください。

API を用いると、以下の操作が行えます。
+ バックアップジョブを開始する
+ バックアップジョブの説明を表示する
+ 復旧ポイントのメタデータを取得する
**注記**  
`BackupSizeInBytes` メタデータは、Amazon EBS ボリューム、Amazon EFS ファイルシステム、Amazon RDS データベース、DynamoDB テーブル、Amazon EC2 インスタンス、Amazon FSx ファイルシステム、Amazon S3 バケットのリソースタイプでサポートされています。このフィールドにはバックアップのサイズがバイト単位で表示され、`DescribeRecoveryPoint` API と AWS Backup コンソールから使用できます。サポートされていないリソースタイプの場合、このフィールドは入力されません。
+ リソース別に復旧ポイントを一覧表示する
+ 復旧ポイントのタグを一覧表示する

### Amazon Redshift クラスターバックアップを表示する
<a name="viewredshiftbackups"></a>

Amazon Redshift テーブルのバックアップをコンソール内で表示および変更するには:

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. **[バックアップボールト]** を選択します。次に、Amazon Redshift クラスターを含むバックアップボールト名をクリックします。

1. バックアップボールトには、概要とバックアップのリストが表示されます。**[復旧ポイント ID]** 列のリンクをクリックできます。

1. 1 つまたは複数の復旧ポイントを削除するには、削除するボックスにチェックを入れます。**[アクション]** ボタンで、**[削除]** を選択できます。

### Amazon Redshift クラスターの復元
<a name="w2aac17c19c31c11c11c11"></a>

詳細については、「[Amazon Redshift クラスターの復元](https://docs.aws.amazon.com/aws-backup/latest/devguide/redshift-restores.html)」を参照してください。

# Amazon Redshift Serverless バックアップ
<a name="redshift-serverless-backups"></a>

## 概要
<a name="redshift-serverless-backups-overview"></a>

AWS Backup は、Amazon Redshift Serverless 名前空間の完全なバックアップ管理を提供します。を通じて AWS Backup、コンソールまたは CLI を使用して Redshift Serverless 手動スナップショットをスケジュールおよび復元できます。

による Redshift Serverless データ保護 AWS Backup には、データウェアハウスをバックアップおよび復元するためのいくつかのオプションがあります。名前空間のスケジュールされたスナップショットやオンデマンドスナップショットを作成できます。次に、そのスナップショット内のすべてのデータベースを、Amazon Redshift でプロビジョニングされたクラスターや Serverless 名前空間に復元することを選択できます。または、1 つのテーブルを復元することもできます。

Redshift Serverless は、自動スナップショットと手動スナップショットの両方を提供します。現在、 AWS Backup は手動スナップショットの管理に使用できますが、自動スナップショットは管理できません。

## Redshift Serverless のバックアップオプション
<a name="redshift-serverless-backups-options"></a>

 AWS Backup コンソールまたは CLI を使用して、オンデマンドまたはバックアッププランの一部としてバックアップを作成できます。

### オンデマンドバックアップを作成する
<a name="redshift-serverless-backups-on-demand"></a>

Redshift Serverless 名前空間のオンデマンドバックアップは、次の手順で作成できます。

------
#### [ Console ]

1. [AWS Backup コンソール](https://console.aws.amazon.com//backup) を開きます。

1. ダッシュボードで、[**オンデマンドバックアップを作成**] を選択します。

1. リソースタイプのドロップダウンメニューで **[Redshift Serverless]** を選択します。

1. バックアップを計画している名前空間を選択します。

1. **[今すぐバックアップを作成]** が選択されていることを確認します。

1. バックアップの保持期間を指定します。

1. 既存のバックアップボールトを選択するか、新しいバックアップボールトを作成します。

1. バックアップに使用する IAM ロールを選択します。

1. 必要に応じて、バックアップにタグを追加します。オンデマンドバックアップにタグを割り当てるには、**[復旧ポイントに追加されたタグ]** を展開し、**[新しいタグを追加]** を選択して、タグキーとタグ値を入力します。

1. **[オンデマンドバックアップを作成]** を選択して、バックアップジョブを開始します。

1. ジョブが開始されると、コンソールに [ジョブ] 画面が表示され、バックアップジョブとそのステータスのリストが表示されます。

------
#### [ AWS CLI ]

**start-backup-job** コマンドを使用します。

**必須パラメータ**
+ `BackupVaultName`
+ `IamRoleArn`
+ `ResourceArn`

**任意指定のパラメータ**
+ `CompleteWindowMinutes`
+ `IdempotencyToken`
+ `Lifecyle`
+ `StartWindowMinutes`

**Example 例**  
次の例では、Redshift Serverless 名前空間のオンデマンドバックアップを作成します。  

```
aws backup start-backup-job \
    --backup-vault-name sample-vault \
    --iam-role-arn arn:aws:iam::account:role/service-role/AWSBackupDefaultServiceRole \
    --resource-arn arn:aws:redshift-serverless:region:account:namespace/namespace-name-UUID
```

------

### バックアッププランで、スケジュールされた Redshift Serverless バックアップを作成する
<a name="redshift-serverless-backups-scheduled"></a>

 AWS Backup コンソールや CLI を使用して Redshift Serverless 名前空間の新しいバックアッププランを作成することも、Redshift Serverless を既存のバックアッププランに追加することもできます。

保護されたリソースであれば、スケジュールされたバックアップに Redshift Serverless 名前空間を含めることができます。 AWS Backup コンソールで Redshift Serverless の保護をオプトインするには、次の手順を実行します。

------
#### [ Console ]

 AWS Backup コンソールで Redshift Serverless の保護をオプトインするには、次の手順を実行します。

1. [AWS Backup コンソール](https://console.aws.amazon.com//backup) を開きます。

1. ナビゲーションペインで、**[保護されたリソース]** を選択します。

1. **[Amazon Redshift Serverless]** を **[オン]** に切り替えます。

1. 既存のプランまたは新しいプランに Redshift Serverless 名前空間を含めるには、「[バックアップする AWS サービスを選択する](assigning-resources.md)」を参照してください。リソースタイプとして *Redshift Serverless* を追加する場合、**[すべての Amazon Redshift 名前空間]** を選択して追加するか、バックアップに含める名前空間の横にあるチェックボックスをオンします。

**[バックアッププランを管理]** では、次のことができます。
+ [バックアッププランを作成](creating-a-backup-plan.md)し、Redshift Serverless を含めます。
+ 既存のバックアッププランを[更新](updating-a-backup-plan.md)して Redshift Serverless を含めます。

------
#### [ AWS CLI ]

**create-backup-plan** を使用するためのガイダンスについては、「[を使用してバックアッププランを作成する AWS CLI](creating-a-backup-plan.md#create-backup-plan-cli)」を参照してください。

Serverless リソースを含めるように既存のプランを変更する場合は、**update-backup-plan** コマンドを使用します。

"BackupSelection": \$1 "Resources" に含める Serverless リソースの ARN (Amazon リソースネーム) の形式は次のとおりです。

```
arn:aws:redshift-serverless:Region:account:snapshot/a12bc34d-567e-890f-123g-h4ijk56l78m9
```

------

スナップショットからの Serverless 名前空間の復元については、「[Amazon Redshift Serverless の復元](redshift-serverless-restore.md)」を参照してください。

# Amazon EKS backups
<a name="eks-backups"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) クラスターは、単一のユニットとしてバックアップできる複数のリソースで構成されています。Amazon EKS クラスターをバックアップすると、 は EKS クラスターの状態と永続的ボリュームバックアップの両方を含む複合復旧ポイント AWS Backup を作成します。

Amazon EKS クラスターがバックアップされると、 でサポートされている Amazon EKS クラスターの状態と永続的ボリュームの復旧ポイントが作成されます AWS Backup。これらの復旧ポイントは、**複合**と呼ばれる包括的な復旧ポイント内でグループ化されます。

Amazon EKS バックアップには 2 つの異なるコンポーネントがあります。
+ *Amazon EKS クラスター状態:* これは Amazon EKS クラスター状態のバックアップです。含まれている内容については、以下の Amazon EKS バックアップの用語を参照してください。
+ *永続ストレージ:* これは、永続ボリュームクレームを介して Amazon EKS クラスターにアタッチされ、EKS アドオン CSI ドライバーでサポートされる永続ストレージ (Amazon EBS、Amazon S3、Amazon Elastic File System) のバックアップです。 [https://docs.aws.amazon.com/eks/latest/userguide/storage.html](https://docs.aws.amazon.com/eks/latest/userguide/storage.html)

## Amazon EKS バックアップの用語
<a name="eks-backup-overview"></a>

Amazon EKS バックアップドキュメントでは、以下の用語が使用されています。Amazon EKS 固有の用語については、[「Amazon EKS ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」を参照してください。

## EKS バックアップの用語
<a name="eks-backup-terminology"></a>
+ **複合復旧ポイント** – Amazon EKS クラスターバックアップ用にネストされた復旧ポイントをグループ化するために使用される復旧ポイント。
+ **ネストされた復旧ポイント** – Amazon EKS クラスターの一部であり、複合復旧ポイントの一部としてバックアップされるリソースの復旧ポイント。
+ **EKS クラスター状態** – クラスター内の Kubernetes リソースの望ましい状態を定義する Kubernetes マニフェスト (YAML ファイルまたは JSON ファイル）。これには、シークレット、設定マップ、ステートフルセット、DaemonSets、ストレージクラス、ストレージマップ、レプリカセット、永続ボリュームクレーム、カスタムリソース定義、ロール、ロールバインディングなどの Kubernetes リソースとデプロイが含まれます。
+ **Amazon EKS クラスター設定の子復旧ポイント** – Amazon EKS クラスターの状態が含まれます。
+ **永続ボリュームの子復旧ポイント** – EKS アドオン CSI ドライバーでサポートされている、サポートされているストレージタイプ (EBS、S3、EFS) の永続ボリュームバックアップが含まれます。 [https://docs.aws.amazon.com/eks/latest/userguide/storage.html](https://docs.aws.amazon.com/eks/latest/userguide/storage.html)

## Amazon EKS バックアップ構造
<a name="eks-backup-creation"></a>

**Amazon EKS バックアップには、次のコンポーネントが含まれます。**
+ Amazon EKS クラスターの状態
+ 永続的ストレージ: Amazon EBS、Amazon EFS、Amazon S3 など、サポートされているストレージタイプのバックアップ

**Amazon EKS Backups には以下のコンポーネントは含まれません。**
+ 外部リポジトリ (ECR、Docker) からのコンテナイメージ
+ EKS クラスターインフラストラクチャコンポーネント (VPCs、サブネットなど)
+ ノード、自動生成されたポッド、イベント、リース、ジョブなどの自動生成された EKS リソース。

**EKS バックアップのセットアップと前提条件 (「バックアップ前」)**
+ **EKS クラスター設定:**
  + EKS クラスターにアクセスするための[アクセスエントリ](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)を作成 AWS Backup するために、 の EKS クラスター[認可モード](https://docs.aws.amazon.com/eks/latest/userguide/setting-up-access-entries.html)を API または API\$1AND\$1CONFIG\$1MAP に設定します。
+ **アクセス許可:**
  + AWS Backupの マネージドポリシー [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#AWSBackupServiceRolePolicyForBackup) には、Amazon EKS クラスターと EBS および EFS 永続ストレージをバックアップするために必要なアクセス許可が含まれています。
  + EKS クラスターに S3 バケットが含まれている場合は、S3 バケットの以下のポリシーと前提条件が文書化されているように追加され、有効になっていることを確認する必要があります。
    + [AWSBackupServiceRolePolicyForS3Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#AWSBackupServiceRolePolicyForS3Backup)
    + [S3 バックアップの前提条件](https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html#s3-backup-prerequisites)
+ **暗号化:**
  + Amazon EKS 子復旧ポイントは、ターゲット Backup Vault の Amazon KMS キーセットで暗号化されます。
  + 永続的ストレージリカバリポイントは、EBS スナップショット、S3 バックアップ、EFS バックアップの各ストレージクラスの現在のサポートに従って暗号化されます。[「 でのバックアップの暗号化」を参照してください。 AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)

## Amazon EKS バックアップを作成する
<a name="eks-backups-options"></a>

バックアップ作成のプロセスは、バックアップジョブと呼ばれます。Amazon EKS クラスターのバックアップジョブのステータスは です。バックアップジョブが終了すると、ステータスは Completed になります。これは、復旧ポイント (バックアップ) が作成されたことを意味します。

### オンデマンド Amazon EKS バックアップの作成
<a name="eks-backups-on-demand"></a>

------
#### [ Console ]

Amazon EKS クラスターのオンデマンドバックアップを作成するには:

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[保護されたリソース]** を選択します。

1. **リソースタイプ**で、**Amazon EKS** を選択します。

1. バックアップする Amazon EKS クラスターの横にあるチェックボックスをオンにします。

1. **[オンデマンドバックアップを作成]** を選択します。

1. バックアップウィンドウ、コールドストレージへの移行、保持期間など、バックアップ設定を構成します。

1. **[オンデマンドバックアップを作成]** を選択します。

------
#### [ AWS CLI ]

を使用して Amazon EKS クラスターのオンデマンドバックアップを作成するには AWS CLI:

**start-backup-job**コマンドを使用します。

```
aws backup start-backup-job \
    --backup-vault-name my-backup-vault \
    --resource-arn arn:aws:eks:us-west-2:123456789012:cluster/my-cluster \
    --iam-role-arn arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole \
    --region us-west-2
```

必要に応じて、ライフサイクル設定などの追加のパラメータを指定します。

```
aws backup start-backup-job \
    --backup-vault-name my-backup-vault \
    --resource-arn arn:aws:eks:us-west-2:123456789012:cluster/my-cluster \
    --iam-role-arn arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole \
    --lifecycle MoveToColdStorageAfterDays=30,DeleteAfterDays=365 \
    --region us-west-2
```

バックアップジョブのステータスをモニタリングします。

```
aws backup describe-backup-job \
    --backup-job-id backup-job-id \
    --region us-west-2
```

------

## Amazon EKS バックアップ ARN 形式
<a name="eks-recovery-points"></a>

Composite Recovery Point arn:*partition*:backup:*region*:*accountId*:recovery-point:composite:eks/*cluster-name*-*timestamp*

子復旧ポイント arn:*partition*:backup:*region*:*accountId*:recovery-point:eks/*cluster-name*-*timestamp*

### Amazon EKS 復旧ポイント
<a name="eks-recovery-point-status"></a>

#### 復旧ポイントのステータス
<a name="eks-recovery-point-status-details"></a>

Amazon EKS クラスターのバックアップジョブが終了すると (ジョブのステータスは `Completed`)、クラスターのバックアップが作成されます。このバックアップは複合復旧ポイントとも呼ばれます。複合復旧ポイントには、`Completed`、`Failed`、`Partial` のいずれかのステータスがあります。

各 Amazon EKS バックアップは、複合復旧ポイントの親バックアップジョブと、各子復旧ポイント (クラスター設定と永続ボリューム) の子バックアップジョブを作成します。
+ 完了したバックアップジョブとは、Amazon EKS クラスター全体とその中のリソースが によって保護されていることを意味します AWS Backup。
+ 失敗ステータスは、バックアップジョブが失敗したことを示します。失敗の原因となった問題が修正されたら、バックアップを再度作成する必要があります。
+ `Partial` ステータスは、クラスター内のすべてのリソースがバックアップされたわけではないことを意味します。これは、クラスター内のリソース (ネストされたリソース) に属する 1 つ以上のバックアップジョブのステータスが 以外の場合に発生する可能性があります`Completed`。`Completed` 以外のステータスになったリソースがあれば、オンデマンドバックアップを手動で作成して、このリソースを再実行できます。
+ `Completed with issues` ステータスは、クラスター内のすべてのリソースがバックアップされたわけではないことを意味します。これは、クラスター内の一部の Kubernetes オブジェクトのバックアップに失敗した場合に発生する可能性があります。バックアップのために失敗したオブジェクト**の通知イベント**をサブスクライブできます。詳細については、[「 を使用した通知オプション」を参照してください AWS Backup。](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html)

複合復旧ポイント内のネストされたリソースのそれぞれに、個別の復旧ポイントがあり、それぞれに独自のステータス (`Completed` または `Failed`) があります。ネストされた復旧ポイントで、ステータスが `Completed` のものは、復元できます。

AWS Backup は、永続的なボリューム復旧ポイントのコールドストレージへのライフサイクル移行をサポートします。通知をサブスクライブして、バックアップジョブのステータスに関するアラートを受信できます。

## 復旧ポイントを管理する
<a name="eks-manage-recovery-points"></a>

複合復旧ポイント (バックアップ) をコピーできます。永続ボリュームの子復旧ポイントは、コピー、削除、関連付け解除、または復元できます。Amazon EKS クラスター状態の子復旧ポイントは、親複合復旧ポイントとの 1:1 の関係を維持しているため、コピー、削除、または関連付け解除することはできません。

ネストされたバックアップを含む複合復旧ポイントは削除できません。複合復旧ポイント内の、ネストされた復旧ポイントを削除した後、または関連付けを解除した後は、複合復旧ポイントを手動で削除することも、バックアッププランのライフサイクルによって削除されるまでそのままにしておくこともできます。

### 復旧ポイントを削除する
<a name="eks-delete-recovery-point"></a>

復旧ポイントは、 コンソールまたは を使用して削除できます AWS CLI。

コンソールを使用して復旧ポイントを削除するには:

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションで、[保護されたリソース] をクリックします。テキストボックスに EKS と入力して、Amazon EKS クラスターのみを表示します。

1. 複合復旧ポイントは [復旧ポイント] ペインに表示されます。各復旧ポイント ID の左側にある [プラス記号 (\$1)] をクリックすると各複合復旧ポイントが展開され、複合に含まれるネストされた復旧ポイントのすべてが表示されます。任意の復旧ポイントの左側にあるチェックボックスをオンにすると、削除する復旧ポイントの選択にその復旧ポイントを含めることができます。

1. [削除] ボタンをクリックします。

コンソールを使用して 1 つ以上の複合復旧ポイントを削除すると、警告ボックスが表示されます。この警告ボックスでは、複合スタック内のネストされた復旧ポイントを含め、複合復旧ポイントを削除する意図の確認を求められます。

API を使用して復旧ポイントを削除するには、DeleteRecoveryPoint コマンドを使用します。

で API を使用する場合は AWS Command Line Interface 、複合ポイントを削除する前に、ネストされたすべての復旧ポイントを削除する必要があります。

### ネストされた復旧ポイントと複合復旧ポイントの関連付けを解除する
<a name="eks-disassociate-recovery-point"></a>

ネストされた復旧ポイントと複合復旧ポイントの関連付けを解除できます (例えば、ネストされた復旧ポイントをそのままにしておき、複合復旧ポイントを削除する場合など)。両方の復旧ポイントはそのまま残りますが、接続は解除されます。つまり、ネストされた復旧ポイントとの関連付けが解除されると、複合復旧ポイントで実行された操作は、ネストされた復旧ポイントには適用されなくなります。Amazon EKS クラスター状態の子復旧ポイントは、親複合復旧ポイントとの 1:1 の関係を維持しているため、関連付けを解除することはできません。

コンソールを使用して復旧ポイントの関連付けを解除することも、API DisassociateRecoveryPointFromParent を呼び出すこともできます。

## 復旧ポイントをコピーする
<a name="eks-copy-recovery-point"></a>

複合復旧ポイントをコピーできます。また、リソースが[クロスアカウントコピーやクロスリージョンコピー](backup-feature-availability.md#features-by-resource)をサポートしている場合には、ネストされた復旧ポイントをコピーすることもできます。

 AWS Backup コンソールを使用して復旧ポイントをコピーするには:

[https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションで**ボールト**をクリックし、コピーする復旧ポイントを含むボールトに移動します。テキストボックスに「」と入力`EKS`して、Amazon EKS クラスターの復旧ポイントのみを表示します。

1. 複合復旧ポイントとネストされた復旧ポイントの両方が復旧ポイント ID ペインの下に表示されます。ネストされた EKS 復旧ポイントを選択してコピーすることはできません。

1. 各複合復旧ポイント ID の左側にある矢印記号をクリックして展開し、複合に含まれるすべてのネストされた復旧ポイントを表示できます。任意の復旧ポイントの左側にある四角いチェックボックスをクリックしてコピーできます。

1. 選択したら、ペインの右上隅にある**アクション**ドロップダウンをクリックし、**コピー**をクリックします。

Amazon EKS バックアップは、すべてのコピータイプをサポートします。
+ 同じリージョン/アカウント
+ クロスアカウント
+ クロスリージョン
+ オプトインリージョン

## 制限事項
<a name="eks-limitations"></a>
+ CSI 移行、ツリー内ストレージプラグイン、または ACK コントローラーを介して CSI ドライバーを使用する永続的ボリュームはサポートされていません。注釈`volume.kubernetes.io/storage-provisioner: ebs.csi.aws.com`は、ボリュームが CSI を使用しているのではなく、どのプロビジョナーがボリュームを管理できるかを示すメタデータであることに注意してください。実際のプロビジョナーは storageClass によって決定されます。
+ CSI ドライバー MountPoints に特定のプレフィックスがアタッチされている Amazon S3 バケットはバックアップできません。特定のプレフィックスではなく、ターゲットとしての Amazon S3 バケットのみがサポートされます。
+ EKS クラスターバックアップの一部としての Amazon S3 バケットバックアップは、スナップショットバックアップのみをサポートします。
+ クロスアカウントでの EFS ファイルシステムのバックアップは、EKS Backups ではサポートされていません。
+ CSI ドライバー経由の Amazon FSx は EKS Backups ではサポートされていません。
+ AWS Backup は、Amazon EKS on AWS Outposts をサポートしていません。
+ [バックアップクォータと復元クォ](aws-backup-limits.html)ータの対象となります。

## 問題で完了したバックアップジョブ
<a name="eks-backup-jobs-completed-with-issues"></a>

Amazon EKS クラスターをバックアップするときに、一部の Kubernetes オブジェクトを取得できない場合があります。この場合、バックアップジョブは完全に失敗するのではなく、 `Completed with issues` ステータスで完了し、次のステータスメッセージが表示されます。
+ 一部の Kubernetes オブジェクトのバックアップに失敗しました。これらの障害の通知を受け取るには、[SNS イベント通知を有効にします](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html)。

Amazon [EKS Metrics Server Add On](https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html) の可用性の問題により、503 Service Unavailable エラーが発生するため、バックアップジョブ中に次の Kubernetes オブジェクトタイプがスキップされる場合があります。[トラブルシューティングのガイダンス](https://repost.aws/knowledge-center/eks-resolve-http-503-errors-kubernetes)については、こちらを参照してください。
+ `metrics.k8s.io`
+ `custom.metrics.k8s.io`
+ `external.metrics.k8s.io`
+ `metrics.eks.amazonaws.com`

## よくある質問
<a name="eks-faq"></a>

1. *「Amazon EKS バックアップの一部として何が含まれていますか?*」

   Amazon EKS クラスターの各バックアップの一部として、 でサポートされている Amazon EKS クラスターの状態と永続的ボリューム AWS Backup がバックアップされます。Amazon EKS クラスターの状態には、クラスター名、IAM ロール、Amazon VPC 設定、ネットワーク設定、ログ記録、暗号化、アドオン、アクセスエントリ、マネージド型ノードグループ、Fargate プロファイル、ポッド ID の関連付け、Kubernetes マニフェストファイルなどの詳細が含まれます。

1. *「`Partial` ステータスはバックアップの作成に失敗したことを意味しますか?」*

   いいえ。一部のステータスでは、一部の復旧ポイントがバックアップされたものの、一部はバックアップされなかったことが示されます。`Completed` バックアップ結果が予期されていたかどうかを確認するには、次の 2 つの条件があります。

   1. クラスター内のリソースに属する 1 つ以上のバックアップジョブが成功しなかったため、ジョブを再実行する必要があります。

   1. ネストされた復旧ポイントが削除されたか、複合復旧ポイントとの関連付けが解除されました。

1. *「バックアップ前に Amazon EKS クラスターにエージェントまたは Amazon EKS アドオンをインストールする必要がありますか?*」

   いいえ。Amazon EKS クラスターにエージェントやアドオンをインストール AWS Backup する必要はありません。唯一の前提条件は、EKS クラスターの[認可モード](https://docs.aws.amazon.com/eks/latest/userguide/setting-up-access-entries.html)を の API または API\$1AND\$1CONFIG\$1MAP に設定 AWS Backup して、EKS クラスターにアクセスするための[アクセスエントリ](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)を作成することです。

1. *「Amazon EKS Backups には Amazon EKS インフラストラクチャコンポーネントまたは Amazon ECR イメージが含まれていますか?*」

   いいえ。Amazon EKS バックアップは、基盤となるインフラストラクチャコンポーネントやコンテナイメージではなく、EKS クラスターの状態とアプリケーションのワークロードに焦点を当てています。

1. *「EKS 複合復旧ポイントをコールドストレージにライフサイクル化できますか?*」

   コールドストレージ層をサポートする基盤となる子復旧ポイントのコールドストレージに移行できます。サポートの全リストについては、[AWS Backup 機能の可用性マトリックス](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource)を参照してください。

1. *「EKS バックアップは増分ですか?*」

   AWS Backup は、現在サポートされている各子復旧ポイントの増分バックアップを取ります。これには、EBS ボリューム、EFS ファイルシステム、S3 バケットが含まれます。EKS クラスター状態の子復旧ポイントはフルバックアップになります。[AWS Backup 機能の可用性マトリックス](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource)を参照してください。

1. *「インデックスを作成して EKS バックアップを検索できますか?*」

   いいえ。ただし、基盤となるストレージタイプがこの機能をサポートするオンデマンドインデックスを作成し、永続ボリュームを検索できます AWS Backup。[AWS Backup 機能の可用性マトリックス](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource)を参照してください。

# Amazon EC2 での SAP HANA のバックアップ
<a name="backup-saphana"></a>

**注記**  
[がサポートするサービス AWS リージョン](backup-feature-availability.md#supported-services-by-region) には、Amazon EC2 インスタンスで SAP HANA データベースバックアップが利用可能な、現在サポートされているリージョンが含まれています。

AWS Backup は、Amazon EC2 インスタンス上の SAP HANA データベースのバックアップと復元をサポートします。

**Topics**
+ [を使用した SAP HANA データベースの概要 AWS Backup](#saphanaoverview)
+ [を使用して SAP HANA データベースをバックアップするための前提条件 AWS Backup](#saphanaprerequisites)
+ [AWS Backup コンソールでの SAP HANA バックアップオペレーション](#saphanabackupconsole)
+ [SAP HANA データベースのバックアップの表示](#saphanaviewbackup)
+ [で AWS CLI for SAP HANA データベースを使用する AWS Backup](#saphanaapicli)
+ [SAP HANA データベースのバックアップのトラブルシューティング](#saphanatroubleshooting)
+ [を使用する場合の SAP HANA 用語の用語集 AWS Backup](#saphanaglossary)
+ [AWS Backup EC2 インスタンスでの SAP HANA データベースのリリースノートのサポート](#saphanareleasenotes)

## を使用した SAP HANA データベースの概要 AWS Backup
<a name="saphanaoverview"></a>

バックアップ作成機能とデータベース復元機能に加えて、SAP 用 Amazon EC2 Systems Manager との AWS Backup の統合により、お客様は SAP HANA データベースを識別してタグ付けすることができます。

AWS Backup は AWS Backint Agent と統合され、SAP HANA のバックアップと復元を実行します。詳細については、「[AWS Backint](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html)」を参照してください。

SAP HANA のバックアップを取る場合、スナップショットとオンデマンドバックアップはフルバックアップです。ただし、point-in-timeリカバリ (PITR) の継続的バックアップを有効にすることで、増分バックアップを実現できます。

## を使用して SAP HANA データベースをバックアップするための前提条件 AWS Backup
<a name="saphanaprerequisites"></a>

バックアップと復元を実行する前に、いくつかの前提条件を満たす必要があります。これらのステップを実行するには、SAP HANA データベースへの管理アクセスと、 AWS アカウントに新しい IAM ロールとポリシーを作成するためのアクセス許可が必要です。

[Amazon EC2 Systems Manager で以下の前提条件](https://docs.aws.amazon.com/ssm-sap/latest/userguide/get-started.html)を満たします。

1. [SAP HANA データベースを実行している Amazon EC2 インスタンスに必要なアクセス許可を設定する](https://docs.aws.amazon.com/ssm-sap/latest/userguide/get-started.html#ec2-permissions)

1. [ で認証情報を登録する AWS Secrets Manager](https://docs.aws.amazon.com/ssm-sap/latest/userguide/get-started.html#register-secrets)

1. [ SAP エージェント AWS Systems Manager 用の AWS Backint と をインストールする](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-installing-configuring.html)

1. [SSM エージェントを検証する](https://docs.aws.amazon.com/ssm-sap/latest/userguide/get-started.html#verify-ssm-agent)

1. [パラメータを確認する](https://docs.aws.amazon.com/ssm-sap/latest/userguide/get-started.html#verification)

1. [SAP HANA データベースを登録する](https://docs.aws.amazon.com/ssm-sap/latest/userguide/get-started.html#register-database)

各 HANA インスタンスは 1 回のみ登録することが、ベストプラクティスです。登録を複数回行うと、同じデータベースに対して複数の ARN が発生する可能性があります。単一の ARN と登録を維持することで、バックアッププランの作成とメンテナンスが簡単になり、バックアップの予期しない重複を減らすこともできます。

## AWS Backup コンソールでの SAP HANA バックアップオペレーション
<a name="saphanabackupconsole"></a>

SAP セットアップの前提条件と SSM が完了すると、EC2 ででの SAP HANA データベースのバックアップと復元が可能になります。

### SAP HANA リソース保護のオプトイン
<a name="saphanaenableoptin"></a>

 AWS Backup を使用して SAP HANA データベースを保護するには、保護されたリソースの 1 つとして SAP HANA をオンにする必要があります。オプトインするには、以下の操作を行います。

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションペインで **[設定]** を選択します。

1. **[サービスのオプトイン]** で、**[リソースを設定]** を選択します。

1. **[SAP HANA on Amazon EC2]** にオプトインします。

1. **[確認]** をクリックします。

これで、Amazon EC2 での SAP HANA のサービスオプトインが有効になります。

### SAP HANA データベースのスケジュールされたバックアップの作成
<a name="saphanascheduledbackup"></a>

[既存のバックアッププランを編集](https://docs.aws.amazon.com/aws-backup/latest/devguide/updating-a-backup-plan.html)して、SAP HANA リソースを追加することも、SAP HANA リソース専用の[新しいバックアッププランを作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html)することもできます。

新しいバックアッププランの作成を選択する場合は、次の 3 つのオプションがあります。

1. **オプション 1: テンプレートから始める**

   1. バックアッププランテンプレートを選択します。

   1. バックアッププラン名を指定します。

   1. **[プランを作成]** をクリックします。

1. **オプション 2: 新しいプランを作成する**

   1. バックアッププラン名を指定します。

   1. オプションとして、バックアッププランに追加するタグを指定します。

   1. バックアップルール設定を指定します。

      1. バックアップルール名を指定します。

      1. 既存のボールトを選択するか、新しいバックアップボールトを作成します。これが、バックアップが保存される場所です。

      1. バックアップ頻度を指定します。

      1. バックアップウィンドウを指定します。

         *注: コールドストレージへの移行は現在サポートされていません*。

      1. 保持期間を指定します。

         *コピー先へのコピーは現在サポートされていません。*

      1. (*オプション*) 復旧ポイントに追加するタグを指定します。

   1. **[プランを作成]** をクリックします。

1. **オプション 3: JSON を使用したプランの定義**

   1. 既存のバックアッププランの JSON 式を変更するか、新しい式を作成して、バックアッププランの JSON を指定します。

   1. バックアッププラン名を指定します。

   1. **[JSON を検証]** をクリックします。

   バックアッププランが正常に作成されたら、次のステップでバックアッププランにリソースを割り当てることができます。

どのプランを使用する場合でも、必ず[リソースを割り当て](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html)ます。システムデータベースとテナントデータベースを含め、どの SAP HANA データベースを割り当てるかを選択できます。また、特定のリソース ID を除外することもできます。

### SAP HANA データベースのオンデマンドバックアップの作成
<a name="saphanaondemandbackup"></a>

作成後すぐに実行される[フルオンデマンドバックアップを作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-on-demand-backup.html)できます。Amazon EC2 インスタンス上の SAP HANA データベースのオンデマンドバックアップはフルバックアップであり、増分バックアップはサポートされていないことに注意してください。

これで、オンデマンドバックアップが作成されました。指定したリソースのバックアップが開始されます。コンソールは、ジョブの進行状況を確認できる **[バックアップジョブ]** ページに移動します。画面上部の青いバナーにあるバックアップジョブ ID をメモしておきます。バックアップジョブのステータスを簡単に確認するために必要となるためです。バックアップが完了すると、ステータスは `Completed` に進みます。バックアップには最大で数時間かかることもあります。

**[バックアップジョブリスト]** を更新して、ステータスの変更を確認します。**[バックアップジョブ ID]** を検索してクリックすると、詳細なジョブステータスを表示することもできます。

### SAP HANA データベースの継続的バックアップ
<a name="saphanacontinuousbackup"></a>

[継続的バックアップ](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html)を作成して、ポイントインタイムリストア (PITR) で使用できます (オンデマンドバックアップでは、リソースは取得時の状態で保存されるのに対し、PITR では一定期間にわたる変更を記録する継続的バックアップを使用する点に注意してください)。

継続的バックアップにより、EC2 インスタンス上の SAP HANA データベースは、精度の 1 秒 (最大 35 日前) 以内に、選択した特定の時間に巻き戻すことで SAP HANA データベースをサポートします。継続的なバックアップは、最初にリソースのフルバックアップを作成し、次にリソースのトランザクションログを定期的にバックアップすることによって機能します。PITR 復元は、完全バックアップにアクセスし、トランザクションログを に復元 AWS Backup するように指示した時刻に再生することで機能します。

 AWS Backup コンソールまたは API AWS Backup を使用して でバックアッププランを作成するときに、継続的バックアップにオプトインできます。

**コンソールを使用して継続的なバックアップを有効にするには**

1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、[**バックアッププラン**] を選択して、[**バックアッププランの作成**] を選択します。

1. [**バックアップルール**]で、[**バックアップルールの追加**] を選択します。

1. **[バックアップルールの設定]** セクションで、**[サポートされているリソースの継続的なバックアップを有効にする]** を選択します。

SAP HANA データベースバックアップの [PITR (ポイントインタイムリストア)](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html) を無効にしても、ログは復旧ポイントの有効期限まで (ステータスが `EXPIRED)` に等しくなるまで) AWS Backup に送信され続けます。SAP HANA 内の別のログバックアップ場所に変更して、 AWS Backupへのログの送信を停止できます。

ステータスが の継続的復旧ポイントは、継続的復旧ポイントが中断された`STOPPED`ことを示します。つまり、SAP HANA から に送信されたログには、データベースへの増分変更 AWS Backup を示すギャップがあります。この期間のギャップ内に発生した復旧ポイントのステータスは `STOPPED.` です。

継続的バックアップ (復旧ポイント) の復元ジョブ中に発生する可能性のある問題については、本ガイドの「[SAP HANA 復元のトラブルシューティング](https://docs.aws.amazon.com/aws-backup/latest/devguide/saphana-restore.html#saphanarestoretroubleshooting)」セクションを参照してください。

## SAP HANA データベースのバックアップの表示
<a name="saphanaviewbackup"></a>

**バックアップジョブのステータスを表示する:**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで **ジョブ**を選択します。

1. バックアップジョブ、復元ジョブ、またはコピージョブを選択すると、ジョブのリストが表示されます。

1. ジョブ ID を検索してクリックすると、詳細なジョブステータスが表示されます。

**ボールト内のすべての復旧ポイントを表示する:**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[バックアップボールト]** を選択します。

1. バックアップボールトを検索してクリックすると、そのボールト内のすべての復旧ポイントが表示されます。

**保護されたリソースの詳細を表示する:**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[保護されたリソース]** を選択します。

1. リソースタイプでフィルタリングして、そのリソースタイプのすべてのバックアップを表示することもできます。

## で AWS CLI for SAP HANA データベースを使用する AWS Backup
<a name="saphanaapicli"></a>

バックアップコンソール内の各アクションには、対応する API 呼び出しがあります。

プログラムで AWS Backup とそのリソースを設定および管理[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartBackupJob.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartBackupJob.html)するには、 API コールを使用して EC2 インスタンス上の SAP HANA データベースをバックアップします。

CLI コマンドとして `start-backup-job` を使用します。

## SAP HANA データベースのバックアップのトラブルシューティング
<a name="saphanatroubleshooting"></a>

ワークフロー中にエラーが発生した場合は、次のエラー例と推奨される解決策を参照してください。

**Python の前提条件**
+ **エラー: SSM for SAP 以降の Python バージョンに関連する Zypper エラー**。Python 3.6 AWS Backup が必要ですが、SUSE 12 SP5 はデフォルトで Python 3.4 をサポートしています。

  **解決策:** 次の手順を実行して、SUSE12 SP5 に複数のバージョンの Python をインストールします。

  1. update-alternatives コマンドを実行して、「/usr/bin/python3」を直接使用する代わりに、「/usr/local/bin/」で Python 3 のシンボリックリンクを作成します。このコマンドは、Python 3.4 をデフォルトバージョンとして設定します。コマンドは次のとおりです: `# sudo update-alternatives —install /usr/local/bin/python3 python3 /usr/bin/python3.4 5` 

  1. 次のコマンドを実行して、代替設定に Python 3.6 を追加します: `# sudo update-alternatives —install /usr/local/bin/python3 python3 /usr/bin/python3.6 2`

  1. 次のコマンドを実行して、代替設定を Python 3.6 に変更します: `# sudo update-alternatives —config python3`

     次の出力が表示されます。

     ```
     There are 2 choices for the alternative python3 (providing /usr/local/bin/python3).
      Selection Path Priority Status
     * 0 /usr/bin/python3.4 5 auto mode
      1 /usr/bin/python3.4 5 manual mode
      2 /usr/bin/python3.6 2 manual mode
     Press enter to keep the current choice[*], or type selection number:
     ```

  1. Python 3.6 に対応する番号を入力します。

  1. Python バージョンをチェックし、Python 3.6 が使用されていることを確認します。

  1. (*オプションですが推奨)* Zypper コマンドが想定どおりに動作することを確認します。

**SAP の検出と登録のための Amazon EC2 Systems Manager**
+ **エラー: SSM for SAP は、 と SSM のパブリックエンドポイントへのアクセスがブロックされているため、ワークロードを検出できませんでした**。 AWS Secrets Manager 

  **解決策:** SAP HANA データベースからエンドポイントに到達可能かどうかをテストします。到達できない場合は、 AWS Secrets Manager 用 Amazon VPC エンドポイントおよび SSM for SAP 用 Amazon VPC エンドポイントを作成できます。

  1. 次のコマンドを実行して、Amazon EC2 host for HANA DB から Secrets Manager へのアクセスをテストします: `aws secretsmanager get-secret-value —secret-id hanaeccsbx_hbx_database_awsbkp`。コマンドが値を返さない場合、ファイアウォールが Secrets Manager サービスエンドポイントへのアクセスをブロックしています。ログは「Secrets Manager からシークレットを取得中」ステップで停止します。

  1. コマンド `aws ssm-sap list-registration` を実行して、SSM for SAP エンドポイントへの接続をテストします。コマンドが値を返さない場合、ファイアウォールが SSM for SAP エンドポイントへのアクセスをブロックしています。

     エラーの例: `Connection was closed before we received a valid response from endpoint URL: “https://ssm-sap.us-west-2.amazonaws.com/register-application"`。

  エンドポイントに到達できない場合、続行するには 2 つのオプションがあります。
  + Secrets Manager および SSM for SAP のパブリックサービスエンドポイントへのアクセスを許可するファイアウォールポートを開きます。または、
  + Secrets Manager と SSM for SAP の VPC エンドポイントを作成し、次の操作を行います。
    + DNSSupport と DNSHostname に対して Amazon VPC が有効になっていることを確認します。
    + VPC エンドポイントで [プライベート DNS 名を許可] が有効になっていることを確認します。
    + SSM for SAP の検出が正常に完了すると、ホストが検出されたことがログに示されます。
+ **エラー: サービスパブリックエンドポイントへのアクセス AWS Backup がブロックされたため、 AWS Backup Backint 接続が失敗します。** は、 `time="2024-01-03T11:39:15-08:00" level=error msg="Storage configuration validation failed: missing backup data plane Id"`または のようなエラーを表示する`aws-backint-agent.log`ことがあります`level=fatal msg="Error performing backup missing backup data plane Id`。また、 AWS Backup コンソールに `Fatal Error: An internal error occured.` が表示される場合があります

  **解決策: **ファイアウォールポートを開いて、サービスエンドポイント (HTTPS) へのアクセスを許可します。このオプションを使用すると、DNS はパブリック IP アドレスを介して AWS サービスへのリクエストを解決します。
+ **エラー: 特殊文字を含む HANA パスワードが原因で、SSM for SAP の登録が失敗します。**エラーの例には、`systemdb` に対して `hdbsql` を使用した後の `Error connecting to database HBX/HBX when validating its credentials.` や `Discovery failed because credentials for HBX/SYSTEMDB either not provided or cannot be validated.`、または HANA データベースの Amazon EC2 インスタンスからテストされた `tenantdb` などがあります。

  ジョブページの AWS Backupコンソールで、バックアップジョブの詳細にエラー `FAILED` を含む のステータスを表示できます`Miscellaneous: b’* 10: authentication failed SQLSTATE: 28000\n’`。

  **解決策: **パスワードに特殊文字 (\$1 など) が含まれていないことを確認します。
+ **エラー: `b’* 447: backup could not be completed: [110507] Backint exited with exit code 1 instead of 0. console output: time...`**

  **解決策:** SAP HANA 用 AWS BackInt エージェントのインストールが正常に完了していない可能性があります。[AWS Backint Agent](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html) と [Amazon EC2 Systems Manager エージェント](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)を SAP アプリケーションサーバーにデプロイするプロセスを再試行してください。
+ **エラー: コンソールは登録後にログファイルと一致しません。**

  SAP コンソール向け SSM for SAP Application Manager には登録が成功したことが表示されますが、検出ログには、HANA DB に接続しようとしたときに、特殊文字を含むパスワードが原因で登録が失敗したことが表示され、登録が成功したことは確認されません。正常に登録されたとコンソールに表示されるが、ログには表示されない場合、バックアップは失敗します。

  **登録ステータスを確認する:**

  1. [SSM コンソール](https://console.aws.amazon.com//systems-manager)にログインします。

  1. 左のナビゲーションから **[コマンドを実行]** をクリックします。

  1. テキストフィールド **[コマンド履歴]** で、登録に使用したインスタンスと等しい値と共に、`Instance ID:Equal:` を入力します。これにより、コマンド履歴がフィルタリングされます。

  1. コマンド ID 列を使用して、ステータスが `Failed` のコマンドを見つけます。次に、**AWSSystemsManagerSAP-Discovery** というドキュメント名を見つけます。

  1. で AWS CLI、 コマンドを実行します`aws ssm-sap register-application status`。返された値が `Error` の場合、登録は失敗しました。

  **解決策: **HANA パスワードに特殊文字 (「\$1」など) が含まれていないことを確認します。

**SAP HANA データベースのバックアップの作成**
+ **Error: AWS Backup console は、SystemDB または TenantDB のオンデマンドバックアップが作成されると、「致命的エラー」というメッセージを表示します。**これが発生するのは、パブリックエンドポイントにアクセスできないためです。この原因は、このエンドポイントへのアクセスをブロックするクライアント側のファイアウォールにあります。

  `aws-backint-agent.log` は、`level=error msg="Storage configuration validation failed: missing backup data plane Id"` や `level=fatal msg="Error performing backup missing backup data plane Id."` などのエラーを表示する場合があります。

  **解決策: ** パブリックエンドポイントへのファイアウォールアクセスを開きます。
+ **エラー: ** `Database cannot be backed up while it is stopped`。

  **解決策:** バックアップするデータベースがアクティブであることを確認してください。データベースデータとログは、データベースがオンラインの場合のみ、バックアップできます。
+ **エラー: ** `Getting backup metadata failed. Check the SSM document execution for more details.`

  **解決策:** バックアップするデータベースがアクティブであることを確認してください。データベースデータとログは、データベースがオンラインの場合のみ、バックアップできます。

**バックアップログのモニタリング**
+ **エラー: ** `Encountered an issue with log backups, please check SAP HANA for details.`

  **解決策:** SAP HANA をチェックして、ログバックアップが SAP HANA AWS Backup から に送信されていることを確認します。
+ **エラー: ** `One or more log backup attempts failed for recovery point.`

  **解決策:** 詳細については SAP HANA を確認します。SAP HANA AWS Backup から にログバックアップが送信されていることを確認します。
+ **エラー: ** `Unable to determine the status of log backups for recovery point.`

  **解決策:** 詳細については SAP HANA を確認します。SAP HANA AWS Backup から にログバックアップが送信されていることを確認します。
+ **エラー: ** `Log backups for recovery point %s were interrupted due to a restore operation on the database.`

  **解決策:** 復元ジョブが完了するまで待ちます。ログバックアップが再開されるはずです。

## を使用する場合の SAP HANA 用語の用語集 AWS Backup
<a name="saphanaglossary"></a>

**データバックアップタイプ:** SAP HANA は、フルバックアップと INC (増分) の 2 種類のデータバックアップをサポートしています。 は、各バックアップオペレーション中に使用されるタイプ AWS Backup を最適化します。

**カタログバックアップ:** SAP HANA は Catalog**. AWS Backup interacts という独自のマニフェストを保持します。新しいバックアップを行うたびに、カタログにエントリが作成されます。

**継続的ログバックアップ (トランザクションログ)**: ポイントインタイムリカバリ (PITR) 機能では、SAP HANA は最新のバックアップ以降のすべてのトランザクションを追跡します。

**システムコピー:** 復元先のデータベースが、復旧ポイントの作成元のソースデータベースと異なる復元ジョブ。

**破壊的復元:** 破壊的復元は、復元ジョブの一タイプで、復元されたデータベースがソースまたは既存のデータベースを削除または上書きするものです。

**フル: **フルバックアップはデータベース全体のバックアップです。

**INC: **増分バックアップは、前回のバックアップ以降に SAP HANA データベースに加えられたすべての変更のバックアップです。

## AWS Backup EC2 インスタンスでの SAP HANA データベースのリリースノートのサポート
<a name="saphanareleasenotes"></a>

現時点ではサポートされていない機能が、以下のとおりあります。
+ 継続的バックアップ (トランザクションログを使用するもの) を他のリージョンやアカウントにコピーすることはできません。スナップショットバックアップは、フルバックアップからサポートされているリージョンとアカウントにコピーできます。
+ Backup Audit Manager とレポートは現在サポートされていません。
+ [がサポートするサービス AWS リージョン](backup-feature-availability.md#supported-services-by-region) には、Amazon EC2 インスタンスで現在サポートされている SAP HANA データベースバックアップのリージョンが含まれています。

# Amazon S3 バックアップ
<a name="s3-backups"></a>

## 概要
<a name="s3-backup-overview"></a>

AWS Backup は、S3 にデータを保存するアプリケーションの一元化されたバックアップと復元、またはデータベース、ストレージ、コンピューティングのための他の AWS のサービスをサポートします。[S3 バックアップでは、多くの機能を使用できます](backup-feature-availability.md#features-by-resource) (Backup Audit Manager を含む)。

で 1 つのバックアップポリシーを使用して AWS Backup 、アプリケーションデータのバックアップの作成を一元的に自動化できます。 は、さまざまな AWS サービスやサードパーティーアプリケーション間でバックアップを一元管理され、暗号化された 1 つの場所 ([バックアップボールト](https://docs.aws.amazon.com/aws-backup/latest/devguide/vaults.html)と呼ばれます) に AWS Backup 自動で整理するため、一元的なエクスペリエンスを通じてアプリケーション全体のバックアップを管理できます。S3 の場合は、継続的バックアップを作成し、S3 に保存されているアプリケーションデータを復元し、ワンクリックでバックアップをポイントインタイムに復元できます。

## バックアップ階層化
<a name="s3-backup-tiering"></a>

Amazon S3 は、低コストのウォームストレージ階層へのバックアップ階層化をサポートする唯一のリソースです。詳細については、[「バックアップ階層化](backup-tiering.md)」を参照してください。

## S3 バックアップの前提条件
<a name="s3-backup-prerequisites"></a>

### Amazon S3 のバックアップと復元のアクセス許可とポリシー
<a name="one-time-permissions-setup"></a>

S3 リソースをバックアップ、コピー、復元するには、ロールに適切なポリシーが必要です。これらのポリシーを追加するには、「[AWS 管理ポリシー」を参照してください](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#aws-managed-policies)。S3 バケットのバックアップと復元に使用するロールに、[AWSBackupServiceRolePolicyForS3Backup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Backup.html) と [AWSBackupServiceRolePolicyForS3Restore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html) を追加します。

十分なアクセス許可がない場合は、組織の管理者 (admin) アカウントの管理者に、目的のロールにポリシーを追加するよう依頼してください。

詳細については、「IAM ユーザーガイド」の「*管理ポリシーとインラインポリシー*」を参照してください。[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)

### バックアップとバージョニング
<a name="s3-backup-versioning"></a>

 AWS Backup Amazon [ S3 で使用するには、S3 バケットで S3 バージョニングを有効にする](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html)必要があります。 Amazon S3

S3 バージョンの場合、「[ライフサイクルの有効期限を設定する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)」ことをお勧めします。

バックアップの開始時にバケット内のすべてのオブジェクト (すべてのバージョンを含む) が復旧ポイント (完了したバックアップ) に保存されます。これには、各オブジェクトの最新バージョン、旧バージョン、削除マーカー、ライフサイクルアクションを保留中のオブジェクトが含まれます。

ストレージコストは、削除が予定されているオブジェクト (期限切れになるオブジェクト) を含む、バックアップ内のすべてのオブジェクトに対して計算されます。CLI またはスクリプトを使用して、有効期限切れが予定されているオブジェクトを対象から削除できます。

S3 ライフサイクルポリシーの設定について詳しくは、[このページ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html)の指示に従ってください。

### Amazon S3 のバックアップに関する考慮事項
<a name="S3-backup-considerations"></a>

S3 リソースをバックアップする際には、以下の点を考慮する必要があります。
+ **フォーカスオブジェクトメタデータのサポート** – タグ、アクセスコントロールリスト (ACLs)、ユーザー定義メタデータ、元の作成日、バージョン ID のメタデータ AWS Backup をサポートします。これにより、元の作成日、バージョン ID、ストレージクラス、および ETag を除くバックアップデータとメタデータをすべて復元できます。
+ S3 オブジェクトを復元すると、元のオブジェクトがチェックサム機能を使用していなくても、 はチェックサム値 AWS Backup を適用します。
+  S3 オブジェクトキー名は、ほとんどの UTF-8 エンコード可能な文字列で構成できます。Unicode 文字 `#x9` \$1 `#xA` \$1 `#xD` \$1 `#x20 to #xD7FF` \$1 `#xE000 to #xFFFD` \$1 `#x10000 to #x10FFFF` を使用できます。

  このリストにない文字を含むオブジェクトキー名は、バックアップから除外される場合があります。
+ **コールドストレージの移行** – AWS Backup ライフサイクル管理ポリシーを使用して、バックアップの有効期限のタイムラインを定義します。S3 バックアップのコールドストレージ移行はサポートされていません。
+ 定期的なバックアップ AWS Backup の場合、 はオブジェクトメタデータへのすべての変更を追跡するために最善を尽くします。ただし、1 分以内にタグまたは ACL を複数回更新すると、 AWS Backup `では、すべての中間状態がキャプチャされない場合があります。
+ AWS Backup は、[SSE-C-encrypted](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html)オブジェクトのバックアップをサポートしていません。 は、バケットポリシー、設定、名前、アクセスポイントなどのバケット設定のバックアップ AWS Backup もサポートしていません。
+ AWS Backup は、 での S3 のバックアップをサポートしていません AWS Outposts。
+ **CloudTrail ログ記録** – データ読み取りイベントをログに記録する場合は、別のターゲットバケットに配信される CloudTrail ログが必要になります。CloudTrail ログを、それを記録するバケットに保存すると、無限ループにより予期しない料金が発生する可能性があります。

  詳細については、「**CloudTrail ユーザーガイド」の「[データイベント](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events)」を参照してください。
+ **サーバーアクセスログ記録** – サーバーアクセスログ記録を有効にする場合は、ログを別のターゲットバケットに配信する必要があります。これらのログを、それを記録するバケットに保存すると、無限ループが発生します。詳細については、「[Amazon S3 サーバーアクセスログを有効にします](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html)」を参照してください。

## サポートされているバケットタイプ、数量、およびオブジェクトサイズ
<a name="bucket-types-and-quotas"></a>

AWS Backup は、Amazon S3 でAmazon S3バックアップおよび復元オペレーションをサポートします。

AWS Backup は、汎用 S3 バケットのバックアップと復元をサポートしています。ディレクトリバケットは、現時点ではサポートされていません

 AWS アカウントで許可されるバケットなどのリソースの数量の上限 (クォータと呼ばれる) は、サービスによって異なります。[Amazon S3 のクォータ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html)は [AWS Backup のクォータ](aws-backup-limits.md)とは異なります。

各 AWS アカウントで、デフォルトで最大 100 個のバケットのバックアップを作成できます。最大 1,000 個までバケットのクォータ引き上げをリクエストできます。

バケット数が 1,000 個を超えるアカウントにはクォータ制限が適用されます。リクエストがクォータを超えると、ジョブが失敗する可能性があります。アカウントで作成されるバケット数を 1,000 個に制限することがベストプラクティスです。

## サポートされている S3 ストレージクラス
<a name="supported-s3-classes"></a>



AWS Backup では、次の S3 [ストレージクラスに保存されている S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)データをバックアップできます。
+ S3 Standard
+ S3 Standard – Infrequent Access (IA)
+ S3 1 ゾーン - IA
+ S3 Glacier インスタント取得
+ S3 Intelligent-Tiering (S3 INT)

ストレージクラス [S3 Intelligent-Tiering (INT)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html#sc-dynamic-data-access) 内のオブジェクトのバックアップは、それらのオブジェクトにアクセスします。このアクセスにより、S3 Intelligent-Tiering がトリガーされ、これらのオブジェクトは Frequent Access に自動的に移行されます。

S3 Standard - Infrequent Access (IA) クラスや S3 One Zone-IA クラスを含む Infrequent Access 階層にアクセスするバックアップは、Frequent Access の S3 ストレージ料金 (Infrequent Access または Archive Instant Access 階層に適用) に移行します。

アーカイブストレージクラスの S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive はサポートされていません。

Amazon S3 のストレージ料金に関する詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。

## S3 バックアップタイプ
<a name="s3-backup-types"></a>

を使用すると AWS Backup、オブジェクトデータ、タグ、アクセスコントロールリスト (ACLs)、ユーザー定義メタデータなど、S3 バケットの次のタイプのバックアップを作成できます。
+ **継続的バックアップ**では、過去 35 日間の任意のポイントインタイムに復元できます。S3 バケットの継続的バックアップは、1 つのバックアッププランでのみ設定してください。

  サポートされているサービスのリストと、 AWS Backup を使って連続バックアップを取る方法については「[ポイントインタイムリカバリ](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html)」を参照してください。
+ **定期的バックアップ**では、データのスナップショットを使用して、指定した期間 (最大 99 年間) データを保持できます。定期的バックアップは、1 時間、12 時間、1 日、1 週間、または 1 年間などの頻度でスケジュールできます。 AWS Backup は、[バックアッププラン](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans.html)で定義したバックアップウィンドウ中に定期的バックアップを行います。

  [がバックアッププランをリソースに適用する方法については](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html)、 AWS Backup 「バックアッププランの作成」を参照してください。

S3 バックアップにはクロスアカウントコピーとクロスリージョンコピーを使用できますが、継続的バックアップのコピーにはポイントインタイムリストア機能はありません。

S3 バケットの継続的バックアップと定期的バックアップは、どちらも同じバックアップボールトにある必要があります。

AWS Backup for S3 は、Amazon EventBridge を介した S3 イベントの受信に依存します。S3 バケット通知設定でこの設定を無効にすると、設定がオフになっているバケットの継続的バックアップは停止します。詳細については、「[EventBridge の使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventBridge.html)」を参照してください。

どちらのバックアップタイプでも、最初のバックアップはフルバックアップで、後続のバックアップは増分バックアップです。

## S3 バックアップタイプの比較
<a name="compare-s3-backup-types"></a>

S3 リソースのバックアップ戦略には、継続的バックアップのみ、定期的 (スナップショット) バックアップのみ、あるいはその両方の組み合わせが含まれます。以下の情報は、組織にとって最適な方法を選択するのに役立ちます。

継続的バックアップの場合のみ、次の項目が該当します。
+ 既存データの最初のフルバックアップが完了すると、S3 バケットデータの変更は発生時に追跡されます。
+ 変更履歴により、継続的バックアップの保持期間中は PITR (ポイントインタイムリストア) を使用できます。復元ジョブを実行するには、復元するポイントインタイムを選択します。
+ 各継続的バックアップの保持期間は最大 35 日間です。
+ CLI で作成したバックアッププランの場合、Amazon S3 の高度なバックアップ設定 (バックアップにタグと ACL を含めるオプションを含む) はデフォルトで有効になっています。これらはバックアップオプションで除外できます。構文の例については、「[Amazon S3 の高度なバックアップ設定](#s3-advanced-backup-settings)」を参照してください。

定期的 (スナップショット) バックアップ（定期的またはオンデマンド）の場合のみ、次の項目が該当します。
+ AWS Backup は S3 バケット全体をスキャンし、各オブジェクトの ACL とタグを取得し、前のスナップショットにあったが、作成中のスナップショットには見つからなかったすべてのオブジェクトに対して Head リクエストを開始します。
+ バックアップはポイントインタイム整合性があります。
+ 記録されるバックアップ日時は、バックアップジョブが作成された時刻ではなく、 がバケットのトラバーサル AWS Backup を完了した時刻です。
+ バケットの最初のバックアップはフルバックアップです。それ以降の各バックアップは増分となり、前回のスナップショットからのデータの変化を表します。
+ 定期的バックアップによって作成されたスナップショットの保持期間は最大 99 年です。

継続的バックアップと定期的/スナップショットバックアップの組み合わせの場合に、次の項目が該当します。
+ 既存データ (各バケット) の最初のフルバックアップが完了すると、バケット内の変更は発生時に追跡されます。
+ 継続的復旧ポイントからポイントインタイムリストアを実行できます。
+ スナップショットはポイントインタイム整合性があります。
+ スナップショットは継続的復旧ポイントから直接取得されることから、バケットを再スキャンする必要がないため、処理を速められます。
+ スナップショットと継続的復旧ポイントはデータ系列を共有するため、スナップショットと継続的復旧ポイント間のデータの保存は重複しません。
+ バックアップにタグや ACLs を含めるなどの高度な Amazon S3 バックアップ設定が`continuous`復旧ポイントに対して変更されると、 はその復旧ポイント AWS Backup を停止し、更新された設定 (複数可) で新しいものを作成します。

S3 バケットの継続的バックアップジョブが実行されている場合でも、定期的な (スナップショット) バックアップジョブを開始できます。ただし、次の動作が適用されます。
+ スナップショットバックアップジョブは、既存の継続的バックアップと同じバックアップオプション (ACL とオブジェクトタグの設定) を使用します。
+ スナップショットジョブに継続的バックアップが使用するバックアップオプションとは異なるバックアップオプションを指定しても、スナップショットジョブは継続的バックアップの設定を使用し、「Completed with issues」ステータスで完了します。

  この場合、次のステータスメッセージが表示されます。`"Periodic/snapshot backup for bucket <bucket name> has different backup options than the continuous backup. When using continuous backups along with snapshot backups for the same bucket, the snapshot will use the same settings for backing up ACLs and Object tags as the continuous backup."`

次の表は、既存の継続的復旧ポイントの BackupOptions を変更するときにフルスキャンが必要になるタイミングを示しています。


**BackupOptions が変更された場合のフルスキャン動作**  

| 以前の BackupOptions | 新しい BackupOptions | フルスキャン | 
| --- | --- | --- | 
| backupACLs と backupObjectTags が有効 | backupACLs と backupObjectTags が無効 | いいえ | 
| backupACLs と backupObjectTags が有効 | backupACLs が有効、backupObjectTags が無効 | いいえ | 
| backupACLs と backupObjectTags が有効 | backupACLs が無効、backupObjectTags が有効 | いいえ | 
| backupACLs と backupObjectTags が無効 | backupACLs と backupObjectTags が有効 | はい | 
| backupACLs が有効、backupObjectTags が無効 | backupACLs と backupObjectTags が有効 | はい | 
| backupACLs が無効、backupObjectTags が有効 | backupACLs と backupObjectTags が有効 | はい | 

## S3 バックアップ完了ウィンドウ
<a name="s3-completion-windows"></a>

以下の表は、S3 バケットの最初のフルバックアップの完了時間の目安となるように、さまざまなサイズのサンプルバケットを示しています。バックアップ時間は、各バケットのサイズ、内容、構成、設定によって異なります。


| [バケットサイズ] | オブジェクト数 | 初期バックアップが完了するまでの推定時間 | 
| --- | --- | --- | 
| 425 GB (ギガバイト) | 1 億 3500 万 | 31 時間 | 
| 800 TB (テラバイト) | 6 億 7000 万 | 38 時間 | 
| 6 PB (ペタバイト) | 50 億 | 100 時間 | 
| 370 TB (テラバイト) | 75 億 | 180 時間 | 

## S3 バックアップのベストプラクティスとコストに関する考慮事項
<a name="bestpractices-costoptimization"></a>

### 大規模なバケットのベストプラクティス
<a name="bucket-size-best-practices"></a>

3 億個を超えるオブジェクトを含むバケットの場合:
+ 3 億個を超えるオブジェクトを含むバケットでは、バケットの最初のフルバックアップ時にバックアップ速度が 1 秒あたり最大 17,000 オブジェクトに達することがあります (増分バックアップでは速度が異なります)。3 億個未満のオブジェクトを含むバケットは、1 秒あたり 1,000 オブジェクトに近い速度でバックアップされます。
+ 継続的バックアップが推奨されます。
+ バックアップのライフサイクルを 35 日以上に予定している場合は、継続的バックアップが保存されているのと同じボールトにあるバケットのスナップショットバックアップを有効にすることもできます。

### バックアップ戦略の最適化
<a name="backup-strategy-optimization"></a>
+ 少なくとも毎日、またはそれ以上の頻度でバックアップを行うアカウントでは、バックアップ内のデータについてのバックアップ間の変更が最小限であれば、継続的バックアップを使用することでコスト上のメリットが得られます。
+ より大きなバケットで、変更の頻度が低いものは、継続的バックアップのメリットがあります。これは、バケット全体のスキャンとオブジェクトごとの複数のリクエストを、既存のオブジェクト (前回のバックアップから変更されていないオブジェクト) に対して実行する必要がない場合にコスト削減につながるためです。
+ 1 億個を超えるオブジェクトを含むバケットで、全体のバックアップサイズに比べて削除率が小さい場合、2 日間の保持期間の継続的バックアップと、保持期間の長いスナップショットバックアップの両方を含むバックアッププランでは、コスト面でのメリットが得られる可能性があります。
+ 定期的 (スナップショット) バックアップ時間は、バケットスキャンが不要なときのバックアッププロセスの開始時間と一致します。継続的バックアップとスナップショットバックアップの両方を含むバケットでは、スナップショットバックアップは継続的復旧ポイントから取得されるため、スキャンは不要です。

### オブジェクトのライフサイクルと削除マーカー
<a name="object-lifecycle-considerations"></a>
+ S3 ライフサイクルポリシーには、「**期限切れのオブジェクト削除マーカーを削除**」というオプション機能があります。この機能をオフにすると、削除マーカー (場合によっては数百万単位) がクリーンアッププランなしで期限切れになります。この機能のないバケットをバックアップすると、時間とコストに影響する問題が 2 つ生じます。
  + 削除マーカーはオブジェクトと同様にバックアップされます。オブジェクトと削除マーカーの比率によっては、バックアップ時間と復元時間が影響を受ける可能性があります。
  + バックアップされるオブジェクトとマーカーにはそれぞれ最低料金が適用されます。各削除マーカーには 128 KiB のオブジェクトと同じ料金がかかります。

### ストレージクラスのコストに関する考慮事項
<a name="storage-class-considerations"></a>
+ 単一の S3-GIR (Amazon S3 Glacier Instant Retrieval) 内の各オブジェクトに対して、 AWS Backup は複数の呼び出しを実行します。それにより、バックアップの実行時に取得料金が発生します。

  S3-IA および S3 One Zone-IA ストレージクラスのオブジェクトを持つバケットにも同様の取得コストが適用されます。

### AWS サービスコストの最適化
<a name="aws-service-cost-optimization"></a>
+ バックアップ戦略の一部として CloudTrail AWS KMS、Amazon CloudWatch、Amazon GuardDuty の機能を使用すると、S3 バケットデータストレージを超える追加コストが発生する可能性があります。これらの機能の調整に関する詳細については、以下を参照してください。
  + *Amazon S3 ユーザーガイド*の [Amazon S3 バケットキーを使用した SSE-KMS のコストの削減](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html)。
  + CloudTrail のコストを削減するには、 AWS KMS イベントを除外し、S3 データイベントを無効にします。
    + ** AWS KMS イベントを除外する: ** *CloudTrail ユーザーガイド*の [コンソールで証跡を作成する (基本的なイベントセレクタ)](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html#creating-a-trail-in-the-console) では、 AWS KMS 証跡からこれらのイベントをフィルタリングするイベントを除外するオプションを使用できます (デフォルト設定にはすべての KMS イベントが含まれます）。
      + KMS イベントをログまたは除外するオプションは、証跡の管理イベントをログに記録する場合にのみ使用できます。管理イベントをログに記録しないように選択した場合は、KMS イベントはログに記録されず、KMS イベントログ設定は変更できません。
      + AWS KMS `Encrypt`、、 などの アクションは`Decrypt`、`GenerateDataKey`通常、大量のイベント (99% 以上) を生成します。これらのアクションは、[**読み取り**] イベントとしてログに記録されるようになりました。`Disable`、`Delete`、および `ScheduleKey` などのボリュームの小さい関連 KMS アクション (通常、KMS イベントボリュームの 0.5% 未満を占める) は、**[書き込み]** イベントとしてログに記録されます。
      + `Encrypt`、`Decrypt`、`GenerateDataKey` のようなボリュームの大きなイベントを除外し、`Disable`、`Delete`、`ScheduleKey` などの関連イベントを記録する場合は、**[書き込み]** 管理イベントを記録することを選択し、**[ AWS KMS イベントの除外]** チェックボックスをオフにします。
    + **S3 データイベントを無効にする:** デフォルトでは、証跡とイベントデータストアはデータイベントを記録しません。コスト削減のため、初回バックアップの前に S3 データイベントを無効にします。
  + CloudWatch コストを削減するには、CloudWatch Logs の設定を無効にするための証跡更新時に、CloudTrail イベントの CloudWatch Logs への送信を停止することができます。
  + 「*Amazon GuardDuty ユーザーガイド*」の「[GuardDuty の使用コストの見積もり](https://docs.aws.amazon.com/guardduty/latest/ug/monitoring_costs.html)」。

## S3 バックアップのメッセージ
<a name="s3-backup-messages"></a>

バックアップジョブが完了または失敗すると、次のメッセージが表示されます。次の表は、ステータスメッセージの考えられる原因を特定するのに役立ちます。


| シナリオ | ジョブのステータス | メッセージ | 例 | 
| --- | --- | --- | --- | 
| スナップショットまたは最初の継続的バックアップで、すべてのオブジェクトのバックアップに失敗しました | `FAILED` | 「No objects were backed up from the source bucket **BucketName**. To get notified of these failures, enable SNS event notifications.」 | バックアップロールには、オブジェクトバージョンの ACL を取得するアクセス許可がありません。したがって、どのオブジェクトもバックアップされません。 | 
| 後続の継続的バックアップで、すべてのオブジェクトのバックアップに失敗しました。 | `COMPLETED` | 「No objects were backed up from the source bucket **BucketName**. To get notified of these failures, enable SNS event notifications.」 |  | 

## Amazon S3 の高度なバックアップ設定
<a name="s3-advanced-backup-settings"></a>

AWS Backup には、Amazon S3 バックアップに含まれるメタデータを制御するための高度な設定が用意されています。必要に応じて、アクセスコントロールリスト (ACL) とオブジェクトタグを除外できます。これは、オブジェクトが ACL とオブジェクトタグなしで設定されている場合に役立ちます。つまり、S3 リソースに ACL やオブジェクトタグを使用しない場合は、バックアップの対象から除外すると便利です。

### ACL とオブジェクトタグのバックアップの設定
<a name="s3-backup-configuration"></a>

ACL とオブジェクトタグのバックアップオプションは、 AWS Backup コンソールまたは を使用して設定できます AWS CLI。

------
#### [ Console ]

**コンソールを使用して ACL とタグのオプションを設定する**

1. [https://console.aws.amazon.com/backup/](https://console.aws.amazon.com/backup/home) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[バックアッププラン]** を選択して、**[バックアッププランを作成]** を選択します。

1. バックアッププランの設定で、**[アドバンストバックアップ設定]** を展開します。

1. Amazon S3 リソースに対して次のオプションを設定します。
   + **[ACL をバックアップ]**: チェックボックスをオンすると ACL が含まれます。オフのままにすると除外されます。

     **[オブジェクトタグをバックアップ]**: チェックボックスをオンにすると、バックアップにオブジェクトタグが含まれます。

1. バックアッププランの設定を完了し、**[プランを作成]** を選択します。

------
#### [ AWS CLI ]

以下のバックアップオプションを使用して、Amazon S3 バックアップでアクセスコントロールリスト (ACL) とオブジェクトタグを選択的に含めたり除外したりできます。

BackupACLs  
オブジェクト ACL をバックアップに含めるかどうかを制御します。ACL を除外するには、`disabled` に設定します。デフォルト: `enabled`

BackupObjectTags  
オブジェクトタグをバックアップに含めるかどうかを制御します。タグを除外するには、`disabled` に設定します。デフォルト: `enabled`

を使用して ACL とタグのオプションを設定する AWS CLI

を使用して ACL とオブジェクトタグのバックアップオプションを設定するには AWS CLI、高度なバックアップ設定で `update-backup-plan` コマンドを使用します。

```
aws backup update-backup-plan \
    --backup-plan-id "your-backup-plan-id" \
    --backup-plan '{
        "BackupPlanName": "MyS3BackupPlan",
        "Rules": [{
            "RuleName": "MyS3BackupRule",
            "TargetBackupVaultName": "MyBackupVault",
            "ScheduleExpression": "cron(0 2 ? * * *)",
            "Lifecycle": {
                "DeleteAfterDays": 30
            },
            "RecoveryPointTags": {},
            "CopyActions": [],
            "EnableContinuousBackup": false
        }],
        "AdvancedBackupSettings": [{
            "ResourceType": "S3",
            "BackupOptions": {
                "BackupACLs": "disabled",
                "BackupObjectTags": "disabled"
            }
        }]
    }'
```

`BackupOptions` パラメータでメタデータを含めるかどうかを制御します。
+ `"BackupACLs": "disabled"` - バックアップから ACL を除外します
+ `"BackupObjectTags": "disabled"` - バックアップからオブジェクトタグを除外します
+ `"BackupACLs": "enabled"` - バックアップに ACL を含めます (デフォルト)
+ `"BackupObjectTags": "enabled"` - バックアップにオブジェクトタグを含めます (デフォルト)

------

# Amazon Timestream バックアップ
<a name="timestream-backup"></a>

Amazon Timestream はスケーラブルな時系列データベースで、1 日に最大何兆もの時系列データポイントの保存と分析が可能です。Timestream は、最新のデータをメモリに保持し、履歴データをポリシーに従ってコストが最適化されたストレージ階層に保存することで、コストと時間の節約のために最適化されています。

Timestream データベースにはテーブルがあります。これらのテーブルにはレコードが含まれており、各レコードは時系列内の 1 つのデータポイントです。時系列は、株価、Amazon EC2 インスタンスのメモリの使用レベル、温度読み取りなど、時間間隔で記録された一連のレコードです。Timestream テーブルを一元的にバックアップおよび復元 AWS Backup できます。これらのテーブルのバックアップは、同じ組織 AWS リージョン 内の他のアカウントや複数のアカウントにコピーできます。

Timestream は現在ネイティブバックアップおよび復元サービスを提供していないため、 AWS Backup を使用して Timestream テーブルの安全なコピーを作成すると、リソースにセキュリティと耐障害性をさらに強化できます。

## Timestream テーブルのバックアップ
<a name="backuptimestream"></a>

Timestream テーブルは、 AWS Backup コンソールまたは を使用してバックアップできます AWS CLI。

 AWS Backup コンソールを使用して Timestream テーブルをバックアップするには、オンデマンドまたはバックアッププランの一部としての 2 つの方法があります。

### オンデマンド Timestream バックアップの作成
<a name="ondemandtimestreambackups"></a>

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインを使用して、[**保護されたリソース**]、[**オンデマンドバックアップの作成**] の順に選択します。

1. **[オンデマンドバックアップを作成]** ページで、[Amazon Timestream] を選択します。

1. **[リソースタイプ]** に Timestream を選択し、バックアップするテーブル名を選択します。

1. バックアップウィンドウで、**[今すぐバックアップを作成]** が選択されていることを確認します。これにより、すぐにバックアップが開始され、**[保護されたリソース]** ページにクラスターが表示される時間を短縮できます。

1. **[コールドストレージへの移行]** のドロップダウンメニューで、移行設定を設定できます。

1. **[保持期間]** では、バックアップを保持する期間を選択できます。

1. 既存のバックアップボールトを選択するか、新しいバックアップボールトを作成します。[**Create new backup vault (新しいバックアップボールトを作成)**] を選択すると、ボールトを作成する新しいページが開きます。完了すると、[**Create on-demand backup (オンデマンドバックアップを作成)**] ページに戻ります。

1. **IAM ロール**で、**デフォルトロール**を選択します ( AWS Backup デフォルトロールがアカウントに存在しない場合、正しいアクセス許可で作成されます）。

1. *オプションとして*、復旧ポイントにタグを追加できます。オンデマンドバックアップに 1 つ以上のタグを割り当てる場合は、**[キー]** とオプションの **[値]**] を入力して、**[タグを追加]** を選択します。

1. **[オンデマンドバックアップを作成]** を選択します。**[ジョブ]** ページに移動し、ジョブのリストが表示されます。

1. クラスターの **[バックアップジョブ ID]** を選択すると、そのジョブの詳細が表示されます。`Completed`、`In Progress`、または `Failed` のステータスが表示されます。表示されるステータスを更新するには、[更新] ボタンをクリックします。

### バックアッププランで、スケジュールされた Timestream バックアップを作成する
<a name="scheduledtimestreambackups"></a>

保護されたリソースであれば、スケジュールされたバックアップに Timestream テーブルを含めることができます。Amazon Timestream テーブルの保護をオプトインするには:

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. ナビゲーションペインで、**[保護されたリソース]** を選択します。

1. Amazon Timestream を **[オン]** に切り替えます。

1. 既存のプランまたは新しいプランに Timestream テーブルを含めるには、「[コンソールへのリソースの割り当て](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html#assigning-resources-console)」を参照してください。

**[バックアッププランを管理]** で、[バックアッププランを作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html)して Timestream テーブルを含めるか、[既存のプランを更新](https://docs.aws.amazon.com/aws-backup/latest/devguide/updating-a-backup-plan.html)して Timestream テーブルを含めるかを選択できます。リソースタイプとして **Timestream を追加する場合、**[すべての Timestream テーブル]** を追加するか、**[特定のリソースタイプを選択]** で、追加するテーブルの横にあるチェックボックスをオンにできます。

Timestream テーブルから最初に作成されるバックアップは、フルバックアップになります。それ以降のバックアップは増分バックアップになります。

バックアッププランを作成または変更したら、左側のナビゲーションにある [バックアッププラン] に移動します。指定したバックアッププランでは、**[リソース割り当て]** にクラスターが表示されるはずです。

### プログラムによるバックアップ
<a name="timestreambackupapi"></a>

オペレーション `start-backup-job` を使用することができます。以下のパラメータを含めます。

```
aws backup start-backup-job \
--backup-vault-name backup-vault-name \
--resource-arn arn:aws:timestream:region:account:database/database-name/table/table-name \
--iam-role-arn arn:aws:iam::account:role/role-name \
--region AWS リージョン \
--endpoint-url URL
```

## Timestream テーブルのバックアップを表示する
<a name="viewtimestreambackups"></a>

Timestream テーブルのバックアップをコンソール内で表示および変更するには:

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. **[バックアップボールト]** を選択します。次に、Timestream テーブルを含むバックアップボールト名をクリックします。

1. バックアップボールトには、概要とバックアップのリストが表示されます。

   1. **[復旧ポイント ID]** 列のリンクをクリックするか、

   1. 復旧ポイント ID の左側にあるチェックボックスをオンにして **[アクション]** をクリックすると、不要になった復旧ポイントを削除できます。

## Timestream テーブルを復元する
<a name="w2aac17c19c41c13"></a>

[Timestream テーブルを復元する](https://docs.aws.amazon.com/aws-backup/latest/devguide/timestream-restore.html)方法を確認する 

# 仮想マシンのバックアップ
<a name="vm-backups"></a>

AWS Backup は、オンプレミスの VMware 仮想マシン (VMs) と、 の VMware Cloud" (VMC) および の VMware Cloud" (VMC) VMs の VM に対して、一元化 AWS され自動化されたデータ保護をサポートします AWS Outposts。オンプレミス仮想マシンと VMC 仮想マシンから にバックアップできます AWS Backup。その後、 AWS Backup から、オンプレミス VM、VMC 内の VM、または VMC on AWS Outpostsに復元できます。

AWS Backup は、VM 検出、バックアップスケジューリング、保持管理、低コストのストレージ階層、クロスリージョンおよびクロスアカウントコピー、 AWS Backup ボールトロックと AWS Backup Audit Manager のサポート、ソースデータから独立した暗号化、バックアップアクセスポリシーなど、フルマネージド型の AWSネイティブ VM バックアップ管理機能も提供します。機能と詳細の完全なリストについては、「[リソース別の機能の可用性](backup-feature-availability.md#features-by-resource) テーブル」を参照してください。

 AWS Backup を使用して、[VMware Cloud" on AWS Outposts](https://aws.amazon.com/vmware/aws-services/)上の仮想マシンを保護できます。 AWS Outposts は、VMware Cloud" on が接続され AWS リージョン ている に VM バックアップ AWS Backup を保存します。 AWS Backup VMware Cloud" on を使用してアプリケーションデータの低レイテンシーおよびローカルデータ処理ニーズを満たす場合、 を使用して VMware Cloud" AWS Outposts AWS Backup VMs を保護できます。データレジデンシーの要件に基づいて、 AWS Outposts が接続され AWS リージョン ている親にアプリケーションデータのバックアップ AWS Backup を保存できます。

## サポートされている VM
<a name="supported-vms"></a>

AWS Backup は、VMware vCenter によって管理される仮想マシンをバックアップおよび復元できます。

**現在サポートされているもの:**
+ vSphere 8、7.0、および 6.7
+ 1 KiB の倍数である仮想ディスクサイズ
+ オンプレミスおよび 上の VMC の NFS、VMFS、および VSAN データストア AWS
+ オンプレミス VMware AWS のソース VMs から にデータをコピーするための SCSI Hot-Add and Network Block Device Secure Sockets Layer (NBDSSL) トランスポートモード
+ VMware Cloud on 上の VMs を保護するためのホット追加モード AWS

**現在サポートされていないもの:**
+ RDM (raw ディスクマッピング) ディスクまたは NVMe コントローラとそのディスク
+ 独立した永続ディスクモードと独立した永続でないディスクモード

## バックアップの整合性
<a name="backup-consistency"></a>

AWS Backupは、デフォルトでは、仮想マシンの VMware Tools 静止設定を使用して、アプリケーションの整合性のある仮想マシンのバックアップをキャプチャします。アプリケーションが VMware Tools と互換性がある場合、バックアップはアプリケーションの一貫性を保ちます。休止機能が使用できない場合、 はクラッシュコンシステントバックアップ AWS Backup をキャプチャします。リストアをテストして、バックアップが組織のニーズを満たしていることを確認します。

## Backup ゲートウェイ
<a name="backup-gateway"></a>

Backup Gateway は、VMware VMs を接続するために VMware インフラストラクチャにデプロイするダウンロード可能な AWS Backup ソフトウェアです AWS Backup。ゲートウェイは VM 管理サーバーに接続して VM を検出し、VM を検出し、データを暗号化し、効率的にデータを AWS Backupに転送します。次の図は、Backup ゲートウェイが VM に接続する方法を示しています。

![\[バックアップゲートウェイは、VMware 環境を接続する OVF テンプレートです AWS Backup。\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/Horizon.png)


Backup ゲートウェイソフトウェアをダウンロードするには、[ゲートウェイの使用](working-with-gateways.md) の手順に従います。

### VM ソフトウェアのダウンロード
<a name="download-vm-software"></a>

バックアップゲートウェイは、VMware インフラストラクチャにデプロイする OVF (Open Virtualization Format) テンプレートとして配布されます。ゲートウェイソフトウェアVMs を検出し、データを暗号化し、データを効率的に転送 AWS Backup することで、VMware VMsを に接続します AWS Backup。

OVF テンプレートを取得するには、 AWS Backup コンソールを使用します。

1.  AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションペインの**外部リソース**で、**ゲートウェイ**を選択します。

1. [**Create gateway (ゲートウェイの作成) **] を選択します。

1. **ゲートウェイのセットアップ**セクションで、OVF テンプレートをダウンロードし、VMware 環境にデプロイします。

VPC (仮想プライベートクラウド) エンドポイントの詳細については、[AWS Backup 「」および AWS PrivateLink 「接続](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-network.html#backup-privatelink)」を参照してください。

Backup ゲートウェイには別に、 AWS Backup API から保持された独自の API が付属しています。Backup ゲートウェイ API アクションのリストを表示するには、「[Backup ゲートウェイアクション](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_Operations_AWS_Backup_Gateway.html)」を参照してください。Backup ゲートウェイ API データタイプのリストを表示するには、「[Backup ゲートウェイのデータタイプ](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_Types_AWS_Backup_Gateway.html)」を参照してください。

## エンドポイント
<a name="backup-gateway-endpoints"></a>

現在パブリックエンドポイントを使用している既存のユーザーが、VPC（Virtual Private Cloud）エンドポイントに切り替える場合は、[AWS PrivateLink](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-network.html#backup-privatelink) を使用して [VPC エンドポイントで新しいゲートウェイを作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-gateways.html#create-gateway)し、既存のハイパーバイザーをゲートウェイに関連付けた後、パブリックエンドポイントを含む[ゲートウェイを削除](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-gateways.html#edit-gateway)できます。

# Backup ゲートウェイを使用するようにインフラストラクチャを構成する
<a name="configure-infrastructure-bgw"></a>

Backup ゲートウェイでは、仮想マシンをバックアップおよび復元するために、次のネットワーク、ファイアウォール、およびハードウェア構成が必要です。

## ネットワーク構成
<a name="bgw-network-configuration"></a>

バックアップゲートウェイを操作するには、許可されている特定のポートが必要です。次のポートを許可します。

1. **TCP 443 アウトバウンド**
   + ソース: Backup ゲートウェイ
   + 送信先: AWS
   + 使用: Backup ゲートウェイが と通信できるようにします AWS。

1. **TCP 80 インバウンド**
   + ソース: への接続に使用するホスト AWS マネジメントコンソール
   + デスティネーション: Backup ゲートウェイ
   + 使用: ローカルシステムでバックアップゲートウェイのアクティベーションキーを取得します。ポート 80 は Backup ゲートウェイのアクティブ化中のみ使用されます。ポート 80 をパブリックにアクセス可能に AWS Backup する必要はありません。ポート 80 へのアクセスに必要なレベルはネットワークの設定によって決まります。からゲートウェイをアクティブ化する場合 AWS マネジメントコンソール、コンソールに接続するホストはゲートウェイのポート 80 にアクセスできる必要があります。

1. **UDP 53 アウトバウンド**
   + ソース: Backup ゲートウェイ
   + デスティネーション: ドメインネームサービス (DNS) サーバー
   + 使用: Backup ゲートウェイが DNS と通信できるようにします。

1. **TCP 22 アウトバウンド**
   + ソース: Backup ゲートウェイ
   + 送信先: サポート
   + 使用: サポート がゲートウェイにアクセスして問題に対応できるようにします。ゲートウェイの通常のオペレーションでは、このポートは開いておく必要はありませんが、トラブルシューティングでは開かなくてはなりません。

1. **UDP 123 アウトバウンド**
   + ソース: NTP クライアント
   + デスティネーション: NTP サーバー
   + 使用: 仮想マシン時間をホスト時間に同期するためにローカルシステムで使用されます。

1. **TCP 443 アウトバウンド**
   + ソース: Backup ゲートウェイ
   + 送信先: VMware vCenter
   + 使用: Backup ゲートウェイが VMware vCenter と通信できるようにします。

1. **TCP 443 アウトバウンド**
   + ソース: Backup ゲートウェイ
   + 送信先: ESXi ホスト
   + 使用: Backup ゲートウェイが ESXi ホストと通信できるようにします。

1. **TCP 902 アウトバウンド**
   + ソース: Backup ゲートウェイ
   + 送信先: VMware ESXi ホスト
   + 使用: Backup ゲートウェイ経由でのデータ転送に使用されます。

上記のポートは Backup ゲートウェイに必要です。 AWS Backup用の Amazon VPC エンドポイントを設定する方法の詳細については、「[VPC エンドポイントを作成する](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-network.html#backup-privatelink)」を参照してください。

## ファイアウォールの設定
<a name="bgw-firewall-configuration"></a>

バックアップゲートウェイは、通信するために次のサービスエンドポイントにアクセスする必要があります Amazon Web Services。ファイアウォールまたはルーターを使用してネットワークトラフィックをフィルタリングまたは制限する場合は、これらのサービスエンドポイントに対し AWSへのアウトバウンド通信を許可するように、対象のファイアウォールおよびルーターを設定する必要があります。Backup ゲートウェイとサービスポイント間の HTTP プロキシの使用はサポートされていません。

**エンドポイントタイプ**

**標準エンドポイント**: ゲートウェイアプライアンスと 間の IPv4 トラフィックをサポートします AWS。

以下のサービスエンドポイントは、すべてのゲートウェイが制御パス (`anon-cp`、`client-cp`、`proxy-app`)およびデータパス (`dp-1`) 操作のために必要とするものです。

```
anon-cp.backup-gateway.region.amazonaws.com:443  
client-cp.backup-gateway.region.amazonaws.com:443  
proxy-app.backup-gateway.region.amazonaws.com:443  
dp-1.backup-gateway.region.amazonaws.com:443
```

**デュアルスタックエンドポイント**: ゲートウェイアプライアンスと 間の IPv4 トラフィックと IPv6 トラフィックの両方をサポートします AWS。

コントロールパス (アクティベーション、コントロールプレーン、プロキシ) およびデータパス (データプレーン) オペレーションには、すべてのゲートウェイで次のデュアルスタックサービスエンドポイントが必要です。

```
activation-backup-gateway.region.api.aws:443  
controlplane-backup-gateway.region.api.aws:443  
proxy-backup-gateway.region.api.aws:443  
dataplane-backup-gateway.region.api.aws:443
```

## VMware で複数の NIC に対するゲートウェイの設定
<a name="bgw-multinic"></a>

複数の仮想ネットワークインターフェイス接続 (NICs) をゲートウェイにアタッチし、内部トラフィック (ハイパーバイザーへのゲートウェイ) と外部トラフィック (ゲートウェイ AWS) を個別に送信することで、内部トラフィックと外部トラフィックに別々のネットワークを維持できます。

デフォルトでは、 AWS Backup ゲートウェイに接続された仮想マシンには 1 つのネットワークアダプタ () があります`eth0`。このネットワークには、ハイパーバイザー、仮想マシン、および広範なインターネットと通信するネットワークゲートウェイ (Backup ゲートウェイ) が含まれます。

以下は、複数の仮想ネットワークインターフェイスを使ったセットアップの例です。

```
            eth0:
            - IP: 10.0.3.83
            - routes: 10.0.3.0/24
            
            eth1:
            - IP: 10.0.0.241
            - routes: 10.0.0.0/24
            - default gateway: 10.0.0.1
```
+ この例では、IP `10.0.3.123` を用いたハイパーバイザーへの接続となっており、ゲートウェイは `eth0` を使用します。ハイパーバイザーが `10.0.3.0/24` ブロックの一部であるためです。
+ IP `10.0.0.234` を用いてハイパーバイザーに接続するには、ゲートウェイは、`eth1` を使用します
+ ローカルネットワーク外の IP (例: `34.193.121.211`) に接続するには、ゲートウェイは、`10.0.0.0/24` ブロック内にあるデフォルトゲートウェイ (`10.0.0.1`) にフォールバックし、そのまま `eth1` に接続します

ネットワークアダプタを追加する最初の手順は、vSphere クライアントで行われます。

1. VMware vSphere クライアントでゲートウェイ仮想マシンのコンテキストメニューを (右クリックで) 開き、**[設定を編集]** を選択します。

1. **[仮想マシンのプロパティ]** ダイアログボックスの **[仮想ハードウェア]** タブで、**[新しいデバイスの追加]** メニューを開き、**[ネットワークアダプタ]** を選択して新しいネットワークアダプタを追加します。

1. 

   1. **[新しいネットワーク]** の詳細を展開して、新しいアダプタを設定します。

   1. **[パワーオン時に接続]** が選択されていることを確認します。

   1. **アダプタのタイプ** については、「[ESXi と vCenter Server のドキュメント](https://docs.vmware.com/en/VMware-vSphere/index.html)」の「ネットワークアダプタのタイプ」を参照してください。

1. **[OK]** をクリックして、新しいネットワークアダプタ設定を保存します。

追加のアダプターを設定する次のステップは、 AWS Backup ゲートウェイコンソールで行われます (これは、バックアップやその他のサービスが管理されている AWS マネジメントコンソールと同じインターフェイスではないことに注意してください）。

新しい NIC をゲートウェイ VM に追加したら、以下を実行する必要があります
+ [`Command Prompt`] に移動して、新しいアダプタをオンにします
+ 新しい NIC ごとに固定 IP を設定します
+ 優先する NIC をデフォルトとして設定します

そのためには、以下の操作をします

1. VMware vSphere クライアントで、ゲートウェイ仮想マシンを選択し、**[ウェブコンソールを起動]** して Backup ゲートウェイのローカルコンソールにアクセスします。

   1.  ローカルコンソールへのアクセスの詳細については、「[VMware ESXi によるゲートウェイローカルコンソールへのアクセス](https://docs.aws.amazon.com/storagegateway/latest/tgw/accessing-local-console.html#MaintenanceConsoleWindowVMware-common)」を参照してください。

1. コマンドプロンプトを終了し、[ネットワーク構成] > [固定 IP の設定] に移動し、セットアップ手順に従ってルーティングテーブルを更新します。

   1. ネットワークアダプターのサブネット内に静的 IP を割り当てます。

   1. ネットワークマスクを設定します。

   1. デフォルトゲートウェイの IP アドレスを入力します。これは、ローカルネットワーク外のすべてのトラフィックに接続するネットワークゲートウェイです。

1. クラウドに接続するアダプターをデフォルトデバイスとして指定するには、**[デフォルトアダプターを設定]** を選択します。

1. ゲートウェイのすべての IP アドレスは、ローカルコンソールと、VMware vSphere の仮想マシンの概要ページの両方に表示できます。

## VMware のアクセス権限
<a name="bgw-vmware-permissions"></a>

このセクションでは、 AWS Backup gatewayを使用するために最低限必要な VMware アクセス許可を一覧表示します。これらのアクセス権限は、Backup ゲートウェイが仮想マシンを検出、バックアップ、および復元するために必要です。

VMware Cloud" on AWS または VMware Cloud" on で Backup ゲートウェイを使用するには AWS Outposts、デフォルトの管理者ユーザーを使用する`cloudadmin@vmc.local`か、CloudAdmin ロールを専用ユーザーに割り当てる必要があります。

VMware オンプレミス仮想マシンで Backup ゲートウェイを使用するには、以下に記載されているアクセス許可を持つ専用ユーザーを作成します。

**グローバル**
+ メソッドを無効にする
+ メソッドを有効にする
+ ライセンス
+ ログイベント
+ カスタム属性を管理する
+ カスタム属性を設定する

**vSphere タギ付け**
+ vSphere タグの割り当てまたは割り当て解除

**データストア**
+ 容量を割り当てる
+ データストアを参照する
+ データストアを設定する (vSAN データストア用)
+ 低レベルのファイル操作
+ 仮想マシンのファイルを更新する

**ホスト**
+ 設定
  + 詳細設定
  + ストレージパーティションの設定

**フォルダ**
+ フォルダの作成

**Network**
+ ネットワークを割り当て

**dvPort グループ**
+ 作成
+ Delete

**リソース**
+ 仮想マシンをリソースプールに割り当て

**仮想マシン**
+ 設定の変更
  + ディスクリースを取得する
  + 既存のディスクを追加する
  + 新しいディスクを追加する
  + 詳細設定
  +  設定を変更する
  + raw デバイスを設定する
  + デバイス設定を変更する
  + ディスクを削除する
  + 注釈を設定する
  + ディスク変更の追跡を切り替え
+ インベントリを編集する
  + 既存から作成する
  + 新規作成
  + 登録
  + 削除
  + 登録を解除する
+ インタラクション
  + パワーオフ
  + パワーオン
+ プロビジョニング
  + ディスクアクセスを許可する
  + 読み取り専用ディスクアクセスを許可する
  + 仮想マシンのダウンロードを許可する
+ スナップショットの管理
  + スナップショットの作成
  + スナップショットの削除
  + スナップショットに戻す

# ゲートウェイの使用
<a name="working-with-gateways"></a>

を使用して仮想マシン (VMsをバックアップおよび復元するには AWS Backup、まず Backup ゲートウェイをインストールする必要があります。ゲートウェイは、 Amazon Web Services バックアップをハイパーバイザーに接続する OVF (Open Virtualization Format) テンプレートの形式のソフトウェアです。これにより、仮想マシンを自動的に検出し、バックアップと復元を行うことができます。

1 つのゲートウェイで最大 4 つのバックアップジョブまたは復元ジョブを同時に実行できます。4 つ以上のジョブを同時に実行するには、ゲートウェイをさらに作成してハイパーバイザーに関連付けます。

## ゲートウェイの作成
<a name="create-gateway"></a>

バックアップゲートウェイは、次の 2 つの方法を使用して作成できます。
+ **コンソールメソッド (標準)**: 自動アクティベーションで AWS Backup コンソールを介してゲートウェイを作成します
+ **手動方法**: アクティベーションキーを取得し、 AWS CLI コマンドを使用して、ゲートウェイ VM のローカルコンソールを使用してゲートウェイを作成します。

どちらの方法でも、最初に OVF テンプレートをダウンロードしてデプロイする必要があります (「」を参照[VM ソフトウェアのダウンロード](vm-backups.md#download-vm-software))。

どちらの方法でも、ゲートウェイは IPv6 経由で通信できます。これには、ゲートウェイアプライアンスバージョン 2.x\$1 と、[デュアルスタックエンドポイント](https://docs.aws.amazon.com/aws-backup/latest/devguide/configure-infrastructure-bgw.html#bgw-firewall-configuration)での追加のファイアウォール設定が必要です。

**重要**  
**IPv6 ハイパーバイザーの要件:** ゲートウェイが IPv6 を介してアクティブ化されている場合は、IPv6 アドレスを使用してハイパーバイザーを作成**する必要があります**。例えば、`10.0.0.252` ではなく `2607:fda8:1001:210::252` を使用します。IPv6 ゲートウェイを IPv4 ハイパーバイザーに関連付けると、バックアップジョブと復元ジョブが失敗する可能性があります。

### コンソールメソッド
<a name="create-gateway-console"></a>

**ゲートウェイを作成するには**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左のナビゲーションペインの [**外部リソース**] セクションで、[**ゲートウェイ**] をクリックします。

1. [**Create gateway (ゲートウェイの作成) **] を選択します。

1. **[ゲートウェイの設定]** セクションで、この手順に従って OVF テンプレートをダウンロードしてデプロイします。

#### VMware ソフトウェアのダウンロード
<a name="downloading-vmware-software"></a>

**ハイパーバイザーの接続**

ゲートウェイはハイパーバイザー AWS Backup に接続されるため、仮想マシンのバックアップを作成して保存できます。VMware ESXi でゲートウェイをセットアップするには、「[OVF テンプレート](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-AE61948B-C2EE-436E-BAFB-3C7209088552.html)」をダウンロードします。ダウンロードには約 10 分かかることもあります。

完了したら、次のステップを実行します。

1. VMware vSphere を使用して仮想マシンのハイパーバイザーに接続します。

1. 仮想マシンの [親オブジェクト] を右クリックし、*[OVF テンプレートのデプロイ]* を選択します。  
![\[[OVF テンプレートのデプロイ] メニュー項目。\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/gateway-user-deploy-ovf-template-20.png)

1. **[ローカルファイル]** を選択し、ダウンロードした **aws-appliance-latest.ova** ファイルをアップロードします。  
![\[[OVF テンプレートの選択] パネルのローカルファイルオプション。\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/gateway-user-select-ovf-template-50.png)

1. デプロイウィザードの手順に従ってデプロイします。**[ストレージの選択]** ページで、仮想ディスクフォーマット **[シックプロビジョニング Lazy Zeroed]** を選択します。  
![\[[ストレージを選択] パネルの [シックプロビジョニング (Lazy Zeroed)] オプション。\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/gateway-user-thick-provision-lazy-70.png)

1. OVF をデプロイしたら、ゲートウェイを右クリックして **[設定の編集]** を選択します。

    ![\[The Edit Settings menu item.\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/gateway-user-edit-settings-30.png) 

   1. **[VM オプション]** で、**[VM ツール]** に移動します

   1. **[ホストと時刻を同期]** で、**[起動時と再開時に同期する]** が選択されていることを確認します。  
![\[起動時の同期と VM の再開オプション。\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/gateway-user-synchronize-time-60.png)

1. **[アクション]** メニューから [パワーオン] を選択して、仮想マシンをオンにします。  
![\[[パワーオン] メニュー項目。\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/gateway-user-power-on-vm-40.png)

1. VM の概要から IP アドレスをコピーし、以下に入力します。  
![\[[概要] ページの [IP アドレス] フィールド。\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/images/gateway-user-copy-ip-address-10.png)

VMware ソフトウェアをダウンロードしたら、以下の手順を実行します。

1. [**ゲートウェイの接続**] セクションで、ゲートウェイの **IP アドレス** を入力します。

   1. この IP アドレスを見つけるには、vSphere クライアントに移動します。

   1. **[概要]** タブでゲートウェイを選択します。

   1. **IP アドレス**をコピーし、 AWS Backup コンソールのテキストバーに貼り付けます。

1. **[ゲートウェイの設定]** セクションで、

   1. **[ゲートウェイ名]** を入力します。

   1.  AWS リージョンを確認します。

   1. エンドポイントをパブリックにアクセス可能にするか、Virtual Private Cloud (VPC) でホストするかを選択します。
      + **パブリックアクセス**可能が選択されている場合は、ゲートウェイ接続の IP バージョン (IPv4 または IPv6) を選択します。
      + **VPC** が選択されている場合は、VPC エンドポイントの DNS 名を入力します。詳細については、「[VPC エンドポイントを作成する](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-network.html#backup-privatelink)」を参照してください。

1. *[オプション]* **[ゲートウェイタグ]** セクションでは、**[キー]** と *[オプション]* の **[値]** を入力してタグを割り当てることができます。複数のタグを追加するには、**[別のタグを追加]** をクリックします。

1. プロセスを完了するには、**[ゲートウェイを作成]** をクリックすると、ゲートウェイの詳細ページが表示されます。

### 手動ゲートウェイの作成
<a name="create-gateway-manual"></a>

#### アクティベーションキーの取得
<a name="bgw-activation-key"></a>

ゲートウェイのアクティベーションキーを受け取るには、ゲートウェイ仮想マシン (VM) にウェブリクエストを行うか、ゲートウェイローカルコンソールを使用します。ゲートウェイ VM は、アクティベーションキーを含むレスポンスを返します。アクティベーションキーは、ゲートウェイの設定を指定するための `CreateGateway` API のパラメータの 1 つとして渡されます。

**ヒント**  
ゲートウェイのアクティベーションキーは、未使用の場合 30 分で有効期限が切れます。

**ウェブリクエストを使用したアクティベーションキーの取得**

次の例は、HTTP リクエストを使用してアクティベーションキーを取得する方法を示しています。次の URLs を使用して、ウェブブラウザまたは Linux curl または同等のコマンドを使用できます。

**注記**  
強調表示された変数を、ゲートウェイの実際の値に置き換えてください。指定できる値は次のとおりです。  
*gateway\$1ip\$1address* - ゲートウェイの IPv4 アドレス。例: `172.31.29.201`
*region\$1code* - ゲートウェイをアクティブ化するリージョン。「AWS 全般のリファレンス**」の「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。このパラメータが指定されていない場合、または指定された値がスペルミスであるか、有効なリージョンと一致しない場合、コマンドはデフォルトで `us-east-1` リージョンになります。

IPv4:

```
curl "http://gateway_ip_address/?activationRegion=region_code&gatewayType=BACKUP_VM&endpointType=DUALSTACK&ipVersion=ipv4&no_redirect"
```

IPv6:

```
curl "http://gateway_ip_address/?activationRegion=region_code&gatewayType=BACKUP_VM&endpointType=DUALSTACK&ipVersion=ipv6&no_redirect"
```

**ローカルコンソールを使用したアクティベーションキーの取得**

次の例は、ゲートウェイホストのローカルコンソールを使用してアクティベーションキーを取得する方法を示しています。

1. 仮想マシンコンソールにログインします。

1. **AWS アプライアンスのアクティベーション - 設定**のメインメニュー`0`から、**アクティベーションキーの取得**を選択します。

1. ゲートウェイファミリーの `2` **Backup Gateway** オプションを選択する

1. ゲートウェイをアクティブ化する AWS リージョンを入力します。

1. ネットワークタイプの場合は、パブリック`1`の場合は 、VPC エンドポイント`2`の場合は と入力します。

1. エンドポイントタイプの場合は、標準エンドポイント`1`の場合は 、デュアルスタックエンドポイント`2`の場合は と入力します。

   1. デュアルスタックエンドポイントの場合は、IPv4 `1`の場合は 、IPv6 `2`の場合は を選択します。

1. アクティベーションキーは自動的に入力されます

#### ゲートウェイの作成
<a name="bgw-create-gateway"></a>

アクティベーションキーを取得した後、 を使用してゲートウェイ AWS CLI を作成します。

1. curl コマンドまたはローカルコンソールメソッドを使用してアクティベーションキーを取得する

1. を使用してゲートウェイを作成する。詳細については AWS CLI、*「バックアップゲートウェイ API リファレンス*」の[CreateGateway](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_CreateGateway.html)」を参照してください。

   ```
   aws backup-gateway create-gateway \
                       --region region_code \
                       --activation-key activation_key \
                       --gateway-display-name gateway_name \
                       --gateway-type BACKUP_VM
   ```

1. **外部リソース** → ゲートウェイの下の AWS Backup コンソールに**ゲートウェイが表示されることを確認する**

## ゲートウェイの編集または削除
<a name="edit-gateway"></a>

**ゲートウェイを編集または削除するには**

1. 左のナビゲーションペインの [**外部リソース**] セクションで、[**ゲートウェイ**] をクリックします。

1. [**ゲートウェイ**] セクションで、**ゲートウェイ名**でゲートウェイを選択します。

1. ゲートウェイ名を編集するには、[**編集**] をクリックします。

1. ゲートウェイを削除するには、[**削除**] をクリックして [**ゲートウェイを削除**] を選択します。

   削除されたゲートウェイを再アクティブ化することはできません。ハイパーバイザーに再度接続する場合は、「[ゲートウェイの作成](#create-gateway)」の手順に従ってください。

1. ハイパーバイザーに接続するには、**接続されたハイパーバイザー**セクションで、[**接続**] を選択します。

   各ゲートウェイは 1 つのハイパーバイザーに接続します。ただし、複数のゲートウェイを同じハイパーバイザーに接続して、最初のゲートウェイの帯域幅を超えてそれらの間の帯域幅を増やすことができます。

1. タグを割り当て、編集、または管理するには、[**タグ**] セクションで、[**タグの管理**] を選択します。

## Backup ゲートウェイの帯域幅スロットリング
<a name="backup-gateway-bandwidth-throttling"></a>

**注記**  
この機能は、2022 年 12 月 15 日以降にデプロイされた新しいゲートウェイで利用できるようになります。既存のゲートウェイでは、この新機能は 2023 年 1 月 30 日までにソフトウェアの自動更新により利用できるようになります。ゲートウェイを手動で最新バージョンに更新するには、 AWS CLI コマンド を使用します[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_UpdateGatewaySoftwareNow.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_UpdateGatewaySoftwareNow.html)。

ゲートウェイから へのアップロードスループットを制限 AWS Backup して、ゲートウェイが使用するネットワーク帯域幅の量を制御できます。デフォルトでは、アクティブ化されたゲートウェイのレート制限は設定されていません。

帯域幅レート制限スケジュールは、 AWS Backup コンソールを使用するか、 () を介して API AWS CLI を使用して設定できます[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_PutBandwidthRateLimitSchedule.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_PutBandwidthRateLimitSchedule.html)。帯域幅レート制限スケジュールを使用すると、制限が 1 日または 1 週間を通して自動的に変更されるように設定できます。

帯域幅レート制限は、アップロードされるすべてのデータのスループットを 1 秒あたりに平均して調整することで機能します。アップロードがマイクロ秒単位またはミリ秒単位で帯域幅レート制限を一時的に超えることもありますが、これによって長時間にわたって大きなスパイクが発生することは通常ありません。

最大 20 個の間隔を追加できます。アップロードレートの最大値は 8,000,000 Mbps です。

### AWS Backup コンソールを使用して、ゲートウェイの帯域幅レート制限スケジュールを表示および編集します。
<a name="backup-gateway-view-edit-bandwidth-rate-limit-schedule"></a>

このセクションでは、ゲートウェイの帯域幅レート制限スケジュールを表示および編集する方法について説明します。

**帯域幅レート制限スケジュールを表示および編集するには**

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左のナビゲーションペインで [**ゲートウェイ**] を選択します。[ゲートウェイ] ペインでは、ゲートウェイは名前ごとに表示されます。管理するゲートウェイ名の横にあるラジオボタンをクリックします。

1. ラジオボタンを選択すると、ドロップダウンメニューの **[アクション]** をクリックできるようになります。**[アクション]** をクリックし、**[帯域幅レート制限スケジュールを編集]** をクリックします。現在のスケジュールが表示されます。デフォルトでは、新規または未編集のゲートウェイには、帯域幅レート制限が定義されていません。
**注記**  
ゲートウェイの [詳細] ページの **[スケジュールを管理]** をクリックして [帯域幅の編集] ページに移動することもできます。

1. *(オプション)* **[間隔を追加]** を選択して、設定可能な新しい間隔をスケジュールに追加します。間隔ごとに、次の情報を入力します。

   1. **曜日** — 間隔を適用する定期的な曜日を選択します。選択すると、ドロップダウンメニューの下に曜日が表示されます。曜日の横にある **[X]** をクリックすると削除できます。

   1. **開始時刻** — *[HH:MM]* 24 時間形式を使用して、帯域幅間隔の開始時刻を入力します。時刻は協定世界時 (UTC) で表示されます。

      注: 帯域幅レート制限間隔は、分単位で指定した分の最初から始まります。

   1. **終了時刻** — *[HH:MM]* 24 時間形式を使用して、帯域幅間隔の終了時刻を入力します。時刻は協定世界時 (UTC) で表示されます。
**重要**  
帯域幅レート制限間隔は、分単位で指定した分の最後に終了します。1 時間の終わりに終了する期間をスケジュールするには、「`59`」と入力します。連続する期間を続けてスケジュールする際に、1 時間の開始時に移行し、期間の間に中断がないようにするには、最初の期間の終了時間を「`59`」分と入力します。後の期間の開始時間は、「`00`」分と入力します。

   1. **アップロード速度** — アップロード速度の制限をメガビット/秒 (Mbps) 単位で入力します。最小値は 102 メガバイト/秒 (Mbps) です。

1. *(オプション)* 帯域幅レート制限スケジュールが完了するまで、必要に応じて前のステップを繰り返します。スケジュールから間隔を削除する必要がある場合は、**[削除]** を選択します。
**重要**  
帯域幅レート制限間隔はオーバーラップできません。間隔の開始時刻は、前の間隔の終了時刻より後で、かつ、次の間隔の開始時刻より前である必要があります。間隔の終了時刻は、次の間隔の開始時刻より前である必要があります。

1. 完了したら、**[変更を保存]** ボタンをクリックします。

### を使用して、ゲートウェイの帯域幅レート制限スケジュールを表示および編集します AWS CLI。
<a name="backup-gateway-view-edit-bandwidth-rate-limit-schedule-cli"></a>

[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_GetBandwidthRateLimitSchedule.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_GetBandwidthRateLimitSchedule.html) アクションを使用して、指定したゲートウェイの帯域幅スロットルスケジュールを表示できます。スケジュールが設定されていない場合、スケジュールは空の間隔リストになります。を使用してゲートウェイの帯域幅スケジュール AWS CLI を取得する例を次に示します。

```
aws backup-gateway get-bandwidth-rate-limit-schedule --gateway-arn "arn:aws:backup-gateway:region:account-id:gateway/bgw-gw id"
```

ゲートウェイの帯域幅スロットルスケジュールを編集するには、[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_PutBandwidthRateLimitSchedule.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_PutBandwidthRateLimitSchedule.html) アクションを使用できます。更新できるのはゲートウェイのスケジュール全体のみで、個々の間隔は変更、追加、削除できないことに注意してください。このアクションを呼び出すと、ゲートウェイの以前の帯域幅スロットルスケジュールが上書きされます。

```
aws backup-gateway put-bandwidth-rate-limit-schedule --gateway-arn "arn:aws:backup-gateway:region:account-id:gateway/gw-id" --bandwidth-rate-limit-intervals ...
```

# ハイパーバイザーの操作
<a name="working-with-hypervisors"></a>

が完了したら[ゲートウェイの作成](working-with-gateways.md#create-gateway)、ハイパーバイザーに接続して、そのハイパーバイザーによって管理される仮想マシン AWS Backup を が操作できるようにします。たとえば、VMware 仮想マシンのハイパーバイザーは VMware vCenter Server です。ハイパーバイザーに [AWS Backupに必要なアクセス許可](https://docs.aws.amazon.com/aws-backup/latest/devguide/configure-infrastructure-bgw.html#bgw-vmware-permissions)が設定されていることを確認してください。

## ハイパーバイザーの追加
<a name="add-hypervisor"></a>

**ハイパーバイザーを追加するには、次の手順を実行します。**

1. 左のナビゲーションペインの [**外部リソース**] セクションで、[**ハイパーバイザー**] をクリックします。

1. [**ハイパーバイザーの追加**] を選択します。

1. [**Hypervisor 設定**] セクションで、**ハイパーバイザー名**を入力します。

1. [**vCenter サーバーホスト**] を選択し、ドロップダウンメニューを使用して、[**IP アドレス**] または [**FQDN** (完全修飾ドメイン名)] を選択します。対応する値を入力します。

1.  AWS Backup がハイパーバイザー上の仮想マシンを検出できるようにするには、ハイパーバイザーの**ユーザー名とパスワード**を入力します****。

1. パスワードを暗号化します。[この暗号化を指定する](https://docs.aws.amazon.com/aws-backup/latest/devguide/bgw-hypervisor-encryption-page.html)には、ドロップダウンメニューを使用して特定のサービス管理の KMS キーまたはカスタマー管理の KMS キーを選択するか、**[KMS キーを作成]** を選択します。特定のキーを選択しない場合、 AWS Backup は、サービス所有のキーを使用してパスワードを暗号化します。

1. [**Connecting gateway**] セクションで、ドロップダウンリストを使用して、ハイパーバイザーに接続する Gateway を指定します。

1. [**Test gateway connection**] をクリックして、以前の入力を確認します。

1. **オプションとして、**[ハイパーバイザーのタグ]** セクションで、**[新しいタグを追加]** を選択して、ハイパーバイザーにタグを割り当てることができます。

1. *オプションの* [https://docs.aws.amazon.com/aws-backup/latest/devguide/backing-up-vms.html#backup-gateway-vmwaretags](https://docs.aws.amazon.com/aws-backup/latest/devguide/backing-up-vms.html#backup-gateway-vmwaretags): 仮想マシンで現在使用している VMware タグを最大 10 個追加して AWS 、タグを生成できます。

1. **[ロググループ設定]** パネルでは、[[Amazon CloudWatch Logs]](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) と統合してハイパーバイザーのログを管理することを選択できます (使用状況に応じて標準の [CloudWatch Logs 料金](https://aws.amazon.com/cloudwatch/pricing/)が適用されます)。各ハイパーバイザーは、1 つのロググループに属することができます。

   1. ロググループをまだ作成していない場合は、**[新しいロググループを作成する]** ラジオボタンを選択します。編集中のハイパーバイザーは、このロググループに関連付けられます。

   1. 以前に別のハイパーバイザーのロググループを作成したことがある場合は、そのロググループをこのハイパーバイザーに使用できます。**[既存のロググループを使用する]** を選択します。

   1. CloudWatch のログ記録が必要ない場合は、**[ログ記録の無効化]** を選択します。

1. [**ハイパーバイザーの追加**] をクリックし、その詳細ページに移動します。

**ヒント**  
Amazon CloudWatch Logs (上記のステップ 11 を参照) を使用して、エラーモニタリング、ゲートウェイとハイパーバイザー間のネットワーク接続、ネットワーク設定情報など、ハイパーバイザーに関する情報を取得できます。CloudWatch ロググループの詳細については、「**Amazon CloudWatch Logs ユーザーガイド」の「[ロググループとログストリームの操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」を参照してください。

## ハイパーバイザーによって管理される仮想マシンの表示
<a name="view-vms-by-hypervisor"></a>

**ハイパーバイザー上の仮想マシンを表示するには、次の手順を実行します。**

1. 左のナビゲーションペインの [**外部リソース**] セクションで、[**ハイパーバイザー**] をクリックします。

1. [**ハイパーバイザー**] セクションで、**ハイパーバイザー名**をクリックしてハイパーバイザーを選択し、その詳細ページに移動します。

1. [**ハイパーバイザーの概要**] のセクション内で、[**仮想マシン**] タブを選択します。

1. [**接続された仮想マシン**] セクションに、仮想マシンのリストが自動的に追加されます。

## ハイパーバイザーに接続されたゲートウェイの表示
<a name="view-gateways-by-hypervisor"></a>

**ハイパーバイザーに接続されているゲートウェイを表示するには、次の手順を実行します。**

1. [**ゲートウェイ**] タブを選択します。

1. [**接続されたゲートウェイ**] セクションに、ゲートウェイのリストが自動的に追加されます。

## ハイパーバイザーを追加のゲートウェイに接続する
<a name="add-more-gateways"></a>

バックアップと復元の速度は、ゲートウェイとハイパーバイザー間の接続の帯域幅によって制限される場合があります。1 つ以上の追加のゲートウェイをハイパーバイザーに接続することで、これらの速度を上げることができます。[**接続されたゲートウェイ**] セクションでこれを行うには、次のようになります。

1. **接続** を選択します。

1. ドロップダウンメニューを使用して別のゲートウェイを選択します。または、[**ゲートウェイの作成**] をクリックして、新しいゲートウェイを作成します。

1. **接続** を選択します。

## ハイパーバイザー設定の編集
<a name="edit-hypervisor"></a>

**Test gateway connection** 機能を使用しないと、誤ったユーザー名またはパスワードでハイパーバイザーを追加することがあります。その場合、ハイパーバイザーの接続ステータスを常に `Pending` にします。または、ユーザー名またはパスワードをローテーションしてハイパーバイザーにアクセスすることもできます。次のプロシージャを使用して、この情報を更新します。

**すでに追加したハイパーバイザーを編集するには、次の手順を実行します。**

1. 左のナビゲーションペインの [**外部リソース**] セクションで、[**ハイパーバイザー**] をクリックします。

1. [**ハイパーバイザー**] セクションで、**ハイパーバイザー名**をクリックしてハイパーバイザーを選択し、その詳細ページに移動します。

1. **[編集]** を選択します。

1. 一番上のパネルの名前は、**[ハイパーバイザーの設定]** です。

   1. **vCenter サーバーホスト**では、FQDN (完全修飾ドメイン名) または IP アドレスを編集することもできます。

   1. **オプションとして、ハイパーバイザーの **[ユーザーネーム]** および **[パスワード]** を入力します。

1. **[ロググループ設定]** パネルでは、[[Amazon CloudWatch]](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) と統合してハイパーバイザーのログを管理することを選択できます (使用状況に応じて標準の [CloudWatch 料金](https://aws.amazon.com/cloudwatch/pricing/)が適用されます)。各ハイパーバイザーは、1 つのロググループに属することができます。

   1. ロググループをまだ作成していない場合は、**[新しいロググループを作成する]** ラジオボタンを選択します。編集中のハイパーバイザーは、このロググループに関連付けられます。

   1. 以前に別のハイパーバイザーのロググループを作成したことがある場合は、そのロググループをこのハイパーバイザーに使用できます。**[既存のロググループを使用する]** を選択します。

   1. CloudWatch のログ記録が必要ない場合は、**[ログ記録の無効化]** を選択します。

**ヒント**  
Amazon CloudWatch Logs (上記のステップ 5 を参照) を使用して、エラーモニタリング、ゲートウェイとハイパーバイザー間のネットワーク接続、ネットワーク設定情報など、ハイパーバイザーに関する情報を取得できます。CloudWatch ロググループの詳細については、「**Amazon CloudWatch Logs ユーザーガイド」の「[ロググループとログストリームの操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」を参照してください。

ハイパーバイザーをプログラムで更新するには、CLI コマンド [[update-hypervisor]](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup-gateway/update-hypervisor.html) と [[UpdateHypervisor]](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_UpdateHypervisor.html) API 呼び出しを使用します。

## ハイパーバイザー設定の削除
<a name="delete-hypervisor"></a>

すでに追加されているハイパーバイザーを削除する必要がある場合は、ハイパーバイザー構成を削除して、別のハイパーバイザー構成を追加します。この削除操作は、ハイパーバイザーに接続するための構成に適用されます。ハイパーバイザーは削除されません。

**すでに追加されているハイパーバイザーに接続するための構成を削除するには、次の手順を実行します。**

1. 左のナビゲーションペインの [**外部リソース**] セクションで、[**ハイパーバイザー**] をクリックします。

1. [**ハイパーバイザー**] セクションで、**ハイパーバイザー名**をクリックしてハイパーバイザーを選択し、その詳細ページに移動します。

1. [**削除**]、[**ハイパーバイザーの削除**] の順に選択します。

1. オプション: [ハイパーバイザーの追加](#add-hypervisor) の手順を使用して、削除したハイパーバイザー構成を置き換えます。

## ハイパーバイザーのステータスの理解
<a name="understand-hypervisor-status"></a>

以下では、考えられるハイパーバイザーのステータスと、該当する場合の修復手順について説明します。`ONLINE` ステータスはハイパーバイザーの正常なステータスです。ハイパーバイザーは、ハイパーバイザーが管理する仮想マシンのバックアップと復元に使用されている間を通して、またはそのほとんどにおいて、このステータスになっているはずです。


**ハイパーバイザーのステータス**  

| ステータス | 意味と修復 | 
| --- | --- | 
| ONLINE |  ゲートウェイ AWS Backupに関連付けられたハイパーバイザーを に追加し、ネットワーク経由でそのゲートウェイに接続して、ハイパーバイザーによって管理される仮想マシンのバックアップとリカバリを実行できます。 これらの仮想マシンの[オンデマンドバックアップとスケジュールバックアップ](https://docs.aws.amazon.com/aws-backup/latest/devguide/backing-up-vms.html)はいつでも実行できます。  | 
| PENDING |  ハイパーバイザーを に追加しました AWS Backup が、次のようになります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/working-with-hypervisors.html) ハイパーバイザーのステータスを `PENDING` から `ONLINE` に変更するには、[ゲートウェイを作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-gateways.html#create-gateway)し、[ハイパーバイザーをそのゲートウェイに接続](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-hypervisors.html#add-more-gateways)します。  | 
| OFFLINE |  ハイパーバイザーを に追加 AWS Backup してゲートウェイに関連付けましたが、ゲートウェイはネットワーク経由でハイパーバイザーに接続できません。 ハイパーバイザーのステータスを `OFFLINE` から `ONLINE` に変更するには、[[ネットワーク構成]](https://docs.aws.amazon.com/aws-backup/latest/devguide/configure-infrastructure-bgw.html#bgw-network-configuration) が正しいことを確認します。 問題が解決しない場合は、ハイパーバイザーの IP アドレスまたは完全修飾ドメイン名が正しいことを確認します。正しくない場合は、[正しい情報を使用してハイパーバイザーを再度追加し、ゲートウェイ接続をテスト](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-hypervisors.html#add-hypervisor)します。  | 
| ERROR |  ハイパーバイザーを に追加 AWS Backup してゲートウェイに関連付けましたが、ゲートウェイはハイパーバイザーと通信できません。 ハイパーバイザーのステータスを `ERROR` から `ONLINE` に変更するには、ハイパーバイザーのユーザー名とパスワードが正しいことを確認します。正しくない場合は、[ハイパーバイザー構成を編集](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-hypervisors.html#edit-hypervisor)します。  | 

**次のステップ**

ハイパーバイザーで仮想マシンをバックアップするには、[仮想マシンのバックアップ](backing-up-vms.md) を参照してください。

# 仮想マシンのバックアップ
<a name="backing-up-vms"></a>

[ハイパーバイザーの追加](working-with-hypervisors.md#add-hypervisor) の後に、Backup ゲートウェイは仮想マシンを自動的に一覧表示します。仮想マシンを表示するには、左側のナビゲーションペインで [**ハイパーバイザー**] または [**仮想マシン**] のいずれかを選択します。
+ [**ハイパーバイザー**] をクリックして、特定のハイパーバイザーによって管理されている仮想マシンのみを表示します。このビューでは、一度に 1 台の仮想マシンを操作できます。
+ **仮想マシン**を選択すると、 に追加したすべてのハイパーバイザーのすべての仮想マシンが表示されます AWS アカウント。このビューでは、複数のハイパーバイザーで一部またはすべての仮想マシンを操作できます。

選択したビューに関係なく、特定の仮想マシンでバックアップ操作を実行するには、[**VM 名**] をクリックして、その詳細ページを開きます。仮想マシンの詳細ページは、次の手順の開始点です。

## 仮想マシンのオンデマンドバックアップの作成
<a name="create-on-demand-backup-vm"></a>

[オンデマンド](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-on-demand-backup.html)バックアップは、手動で開始するワンタイムフルバックアップです。オンデマンドバックアップを使用して、バックアップと復元 AWS Backup機能をテストできます。

**仮想マシンのオンデマンドバックアップを作成するには、次の手順を実行します。**

1. **[オンデマンドバックアップを作成]** を選択します。

1. [オンデマンドバックアップの設定](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-on-demand-backup.html)

1. **[オンデマンドバックアップを作成]** を選択します。

1. バックアップジョブのステータス `Completed` がいつかを確認します。左のナビゲーションペインで **[ジョブ]** を選択します。

1. [**Backup Job ID**] を選択して、[**Backup サイズ**] および、[**作成日**] と [**完了日**] 間の経過時間などのバックアップジョブ情報を表示します。

## 増分 VM バックアップ
<a name="vm-incrementalbackups"></a>

新しいバージョンの VMware には、[ブロック変更追跡](https://kb.vmware.com/s/article/1020128)と呼ばれる機能が含まれています。この機能は、仮想マシンのストレージブロックが時間の経過とともに変化するたびにそれを追跡します。 AWS Backup を使用して仮想マシンをバックアップする場合、 は利用可能な場合は CBT データの使用 AWS Backup を試みます。 は CBT データ AWS Backup を使用してバックアッププロセスを高速化します。CBT データがない場合、バックアップジョブは遅くなり、より多くのハイパーバイザーリソースが使用されます。CBT データが有効でない場合や、使用できない場合でも、バックアップは正常に完了します。例えば、仮想マシンまたは ESXi ホストがハードシャットダウンされた場合、CBT データは有効でなくなる可能性や、利用できなくなる可能性があります。

CBT データが無効または使用できない場合、バックアップステータスはメッセージ付きで `Successful` を読み取ります。このような場合、メッセージは、CBT データがない場合、VMware の CBT データの代わりに独自の変更検出メカニズム AWS Backup を使用してバックアップを完了したことを示します。その後のバックアップでは CBT データの使用が再試行され、ほとんどの場合、CBT データは正常に有効で使用可能になります。それでも問題が解決しない場合は、「[VMware のトラブルシューティング」](https://docs.aws.amazon.com/aws-backup/latest/devguide/vm-troubleshooting.html)を参照して対処方法を確認してください。

CBT が正しく機能するためには、以下を満たしている必要があります。
+ ホストは ESXi 4.0 以降である必要があります
+ ディスクを所有する VM には、ハードウェアバージョン 7 以降が必要です
+ CBT は仮想マシンで有効になっている必要があります (デフォルトでは有効になっています)

仮想ディスクで CBT が有効になっているかどうかを確認するには:

1. vSphere クライアントを開き、パワーオフ状態の仮想マシンを選択します。

1. 仮想マシンを右クリックして、**[設定の編集]** > **[オプション]** > **[詳細/一般]** > **[設定パラメータ]** に移動します。

1. オプション `ctkEnabled` は、`True` と等しくなければなりません。

## バックアッププランにリソースを割り当てることにより、仮想マシンのバックアップを自動化させる
<a name="automate-vm-backup"></a>

[バックアップ計画](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans.html)は、ユーザー定義のデータ保護ポリシーで、 AWS サービスとサードパーティーアプリケーションで多数のデータ保護を自動化します。まず、バックアップの頻度、保持期間、ライフサイクルポリシー、その他多くのオプションを指定して、バックアッププランを作成します。バックアッププランを作成するには、「Getting started チュートリアル」を参照してください。

バックアッププランを作成したら、仮想マシンを含む AWS Backupサポートされているリソースをそのバックアッププランに割り当てます。 は、単一の特定のリソースの割り当てや除外、特定のタグを持つリソースの追加など、アカウント内のすべてのリソースを割り当てる[さまざまな方法](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html) AWS Backup を提供します。

既存のリソース割り当て機能に加えて、仮想マシン AWS Backup のサポートには、バックアッププランに仮想マシンをすばやく割り当てるのに役立ついくつかの新機能が導入されています。[**仮想マシン**] ページでは、複数の仮想マシンにタグを割り当てたり、新しい [**計画にリソースを割り当てる**] 機能を使用します。これらの機能を使用して、 AWS Backup ゲートウェイによって既に検出された仮想マシンを割り当てます。

将来追加の仮想マシンを検出して割り当てる予定で、リソース割り当て手順を自動化して将来の仮想マシンを含める場合は、新しい [**グループ割り当ての作成**] 機能を使用します。

## VMware タグ
<a name="backup-gateway-vmwaretags"></a>

[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_VmwareTag.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_VmwareTag.html)は、リソースの管理、フィルタリング、検索に使用できるキーと値のペアです。

VMware タグは、**カテゴリ**と**タグ名**で構成されています。VMware タグは仮想マシンをグループ化するために使用されます。タグ名は仮想マシンに割り当てられるラベルです。カテゴリはタグ名のコレクションです。

 AWS タグでは、UTF-8 文字、数字、スペース、特殊文字 `+ - = . _ : /` の中から文字を使用できます。

仮想マシンでタグを使用する場合、整理しやすいように、一致するタグを最大 10 個まで AWS Backup に追加できます。最大 10 個の VMware タグを AWS タグにマッピングできます。[AWS Backup コンソール](https://console.aws.amazon.com/backup/)では、**[外部ソース] > [仮想マシン] > [ AWS タグ]** または **[VMware タグ]** にあります。

### VMware のタグマッピング
<a name="vmware-tag-mapping"></a>

仮想マシンでタグを使用する場合、より明確で整理しやすいように、一致するタグを最大 10 個まで AWS Backup に追加できます。マッピングはハイパーバイザー上のどの仮想マシンにも適用されます。

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. コンソールで、**[ハイパーバイザーを編集]** に移動します (**[外部リソース]**、**[ハイパーバイザー]** の順にクリックし、[ハイパーバイザー名] をクリックして **[マッピングを管理]** をクリックします)。

1. 最後のペイン**、VMware タグマッピング**には、VMware タグ情報を対応する AWS タグに入力できる 4 つのテキストボックスフィールドが含まれています。4 つのフィールドは、**Vmware タグカテゴリ**、**VMware タグ名**、**AWS タグキー**、**AWS タグ値** (*例: カテゴリ = OS、タグ名 = Windows、 AWS タグキー = OS-Windows、 AWS タグ値 = Windows) です*。

1. 希望の値を入力したら、**[マッピングを追加]** をクリックします。間違えた場合は、**[削除]** をクリックして入力した情報を削除できます。

1. マッピングを追加したら、これらの AWS タグを VMware 仮想マシンに適用するために使用する IAM ロールを指定します。

   「ポリシー [https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#aws-managed-policies](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#aws-managed-policies)」には必要なアクセス許可が含まれています。使用しているロールにこのポリシーをアタッチできます (または管理者にこのポリシーをアタッチしてもらうことができます)。または、使用しているロール用のカスタムポリシーを作成することもできます。

1. 最後に、**[ハイパーバイザーを追加]** または **[保存]** をクリックします。

IAM ロールの信頼関係を変更して backup-gateway.amazonaws.com サービスと backup.amazonaws.com サービスを追加する必要があります。このサービスがないと、タグをマッピングするときにエラーが発生する可能性があります。既存のロールの信頼関係を編集するには、

1. [IAM コンソール](https://console.aws.amazon.com/iamv2/home?region=us-west-2#/home)にログインします。

1. コンソールのナビゲーションペインで、**[ロール]** を選択します。

1. 変更するロールの名前を選択した後、詳細ページの **[信頼関係]** タブを選択します。

1. **[ポリシードキュメント]** に、次の内容を貼り付けます。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Service": [
             "backup.amazonaws.com",
             "backup-gateway.amazonaws.com"
           ]
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }
   ```

------

1. **信頼ポリシーの更新** を選択します。

詳細については、「**AWS Directory Service 管理ガイド」の「[既存のロールの信頼関係の編集](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/edit_trust.html)」を参照してください。

### VMware タグマッピングの表示
<a name="w2aac17c19c43c23c15c23"></a>

[AWS Backup コンソール](https://console.aws.amazon.com/backup/)で、**[外部リソース]** をクリックし、次に **[ハイパーバイザー]** をクリックして、ハイパーバイザー名のリンクをクリックすると、選択したハイパーバイザーのプロパティが表示されます。[概要] ペインには 4 つのタブがあり、最後のタブは **[VMware タグマッピング]** です。マッピングがまだない場合は、「VMware タグマッピングなし」 と表示されます。

ここから、ハイパーバイザーによって検出された仮想マシンのメタデータを同期したり、ハイパーバイザーにマッピングをコピーしたり (複数可）、VMware AWS タグにマッピングされたタグをバックアッププランのバックアップ選択に追加したり、マッピングを管理したりできます。

コンソールで、選択した仮想マシンにどのタグが適用されているかを確認するには、**[仮想マシン]**、[仮想マシン名]、**[AWS タグ]** または **[VMware タグ]** の順にクリックします。この仮想マシンに関連付けられたタグを表示したり、さらにタグを管理したりできます。

### VMware タグマッピングを使用して、仮想マシンをプランに割り当てる
<a name="w2aac17c19c43c23c15c31"></a>

マッピングされたタグを使用して仮想マシンをバックアッププランに割り当てるには、次の操作を行います。

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. コンソールで、ハイパーバイザーの [詳細] ページの [VMware タグマッピング] に移動します (**[外部リソース]**]、**[ハイパーバイザー]**、[ハイパーバイザー名] を順にクリックします)。

1. マッピングされた複数のタグの横にあるチェックボックスをオンにして、それらのタグを、同じバックアッププランに割り当てます。

1. **[リソースの割り当てに追加]** をクリックします。

1. ドロップダウンリストから既存の **[バックアッププラン]** を選択します。または、**[バックアッププランを作成]** を選択して、新しいバックアッププランを作成します。

1. **[確認]** をクリックします。これにより、**[リソースを割り当てる]** ページが開き、値が事前入力された **[タグを使用して選択を絞り込む]** フィールドが表示されます。

### を使用した VMware タグ AWS CLI
<a name="w2aac17c19c43c23c15c37"></a>

AWS Backup は API コール[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_PutHypervisorPropertyMappings.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_PutHypervisorPropertyMappings.html)を使用して、オンプレミスのハイパーバイザーエンティティプロパティを のプロパティにマッピングします AWS。

で AWS CLI、 オペレーション を使用します`put-hypervisor-property-mappings`。

```
aws backup-gateway put-hypervisor-property-mappings \
--hypervisor-arn arn:aws:backup-gateway:region:account:hypervisor/hypervisorId \
--vmware-to-aws-tag-mappings list of VMware to AWS tag mappings \
--iam-role-arn arn:aws:iam::account:role/roleName \
--region AWSRegion 
--endpoint-url URL
```

以下がその例です。

```
aws backup-gateway put-hypervisor-property-mappings \
--hypervisor-arn arn:aws:backup-gateway:us-east-1:123456789012:hypervisor/hype-12345 \
--vmware-to-aws-tag-mappings VmwareCategory=OS,VmwareTagName=Windows,AwsTagKey=OS-Windows,AwsTagValue=Windows \
--iam-role-arn arn:aws:iam::123456789012:role/SyncRole \
--region us-east-1
```

[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_GetHypervisorPropertyMappings.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_GetHypervisorPropertyMappings.html) を使用して、プロパティマッピング情報を用いたサポートもできます。で AWS CLI、 オペレーション を使用します`get-hypervisor-property-mappings`。サンプルのテンプレートを次に示します。

```
aws backup-gateway get-hypervisor-property-mappings --hypervisor-arn HypervisorARN 
--region AWSRegion
```

以下がその例です。

```
aws backup-gateway get-hypervisor-property-mappings \
--hypervisor-arn arn:aws:backup-gateway:us-east-1:123456789012:hypervisor/hype-12345 \
--region us-east-1
```

### API、CLI、または SDK AWS を使用して、 でハイパーバイザーによって検出された仮想マシンのメタデータを同期する
<a name="w2aac17c19c43c23c15c57"></a>

仮想マシンのメタデータを同期できます。これを行うと、マッピングの一部である仮想マシンに存在する VMware タグが同期されます。また、仮想マシン上に存在する VMware タグにマップされた AWS タグが、 AWS 仮想マシンリソースに適用されます。

AWS Backup は API コール[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_StartVirtualMachinesMetadataSync.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_StartVirtualMachinesMetadataSync.html)を使用して、ハイパーバイザーによって検出された仮想マシンのメタデータを同期します。 AWS CLIを使用してハイパーバイザーが検出した仮想マシンのメタデータを同期するには、オペレーション `start-virtual-machines-metadata-sync` を使用します。

テンプレートの例:

```
aws backup-gateway start-virtual-machines-metadata-sync \
--hypervisor-arn Hypervisor ARN 
--region AWSRegion
```

例:

```
aws backup-gateway start-virtual-machines-metadata-sync \
--hypervisor-arn arn:aws:backup-gateway:us-east-1:123456789012:hypervisor/hype-12345 \
--region us-east-1
```

また、[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_GetHypervisor.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_GetHypervisor.html) を使用して、ホスト、ステータス、最新のメタデータ同期のステータスなどのハイパーバイザー情報をサポートすることも、前回成功したメタデータ同期時刻を取得することもできます。で AWS CLI、 オペレーション を使用します`get-hypervisor`。

テンプレートの例:

```
aws backup-gateway get-hypervisor \
--hypervisor-arn Hypervisor ARN 
--region AWSRegion
```

例:

```
aws backup-gateway get-hypervisor \
--hypervisor-arn arn:aws:backup-gateway:us-east-1:123456789012:hypervisor/hype-12345 \
--region us-east-1
```

詳細については、API ドキュメントの「[VmwareTag](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_VmwareTag.html)」と「[VmwareToAwsTagMapping](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_VmwareToAwsTagMapping.html)」を参照してください。

この機能は、2022 年 12 月 15 日以降にデプロイされた新しいゲートウェイで利用できるようになります。既存のゲートウェイでは、この新機能は 2023 年 1 月 30 日までにソフトウェアの自動更新により利用できるようになります。ゲートウェイを手動で最新バージョンに更新するには、 AWS CLI コマンド [UpdateGatewaySoftwareNow](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_UpdateGatewaySoftwareNow.html) を使用します。

例:

```
aws backup-gateway update-gateway-software-now \
--gateway-arn arn:aws:backup-gateway:us-east-1:123456789012:gateway/bgw-12345 \
--region us-east-1
```

## タグを使用した仮想マシンの割り当て
<a name="assign-vms-tags"></a>

によって現在検出された仮想マシン AWS Backupを他の AWS Backup リソースとともに割り当てるには、既存のバックアッププランの 1 つに既に割り当てたタグを割り当てます。または、[新しいバックアッププラン](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html)と新しい[タグベースのリソースの割り当て](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html)を作成できます。バックアッププランは、バックアップジョブを実行するたびに、新しく割り当てられたリソースをチェックします。

**同じタグで複数の仮想マシンにタグを付けるには、次の手順を実行します。**

1. 左のナビゲーションペインで、[**仮想マシン**] を選択します。

1. [**VM 名**] の横にあるチェックボックスをオンにして、すべての仮想マシンを選択します。または、タグ付けする仮想マシン名の横にあるチェックボックスをオンにします。

1. [**Add tags (タグの追加)**] を選択します。

1. [**キー**] タグを入力します。

1. 推奨: [**値**] タグを入力してください。

1. **[確認]** を選択します。

## プランへのリソースの割り当て機能を使用した仮想マシンの割り当て
<a name="assign-vms-to-plan"></a>

リソース AWS Backup を計画に割り当てる機能を使用して、 によって現在検出された仮想マシンを**既存または新規のバックアップ計画に割り当てる**ことができます。

**プランへのリソースの割り当て機能を使用して仮想マシンを割り当てるには、次の手順を実行します。**

1. 左のナビゲーションペインで、[**仮想マシン**] を選択します。

1. [**VM 名**] の横にあるチェックボックスをオンにして、すべての仮想マシンを選択します。または、複数の仮想マシン名の横にあるチェックボックスをオンにして、それらを同じバックアッププランに割り当てます。

1. [**割り当て**]、[**計画にリソースを割り当てる**] の順に選択します。

1. 「**リソース割り当て名**」を入力します。

1. リソース割り当て [**IAM ロール**] をクリックして、バックアップを作成し、リカバリーポイントを管理します。使用する特定の IAM ロールがない場合は、正しいアクセス権限を持つ**デフォルトロール**を推奨します。

1. [**バックアップ計画**] セクションで、ドロップダウンリストから既存の**バックアップ計画**を選択します。または、[**バックアッププランの作成**] の順にクリックして、新しいバックアッププランを作成します。

1. **リソースの割り当て**を選択します。

1. オプション: **Backup プランの表示**を選択して、仮想マシンがバックアッププランに割り当てられていることを確認します。次に、[**リソースの割り当て**] セクションで、リソースの割り当ての [**名前**] を選択します。

## グループ割り当ての作成機能を使用した仮想マシンの割り当て
<a name="assign-vms-group-assignment"></a>

仮想マシンの前述の 2 つのリソース割り当て機能とは異なり、**グループ割り当ての作成**機能は、現在 によって検出された仮想マシンだけでなく AWS Backup、定義したフォルダまたはハイパーバイザーで将来検出された仮想マシンも割り当てます。

また、**グループ割り当ての作成**機能を使用するためにチェックボックスを選択する必要はありません。

**プランへのリソースの割り当て機能を使用して仮想マシンを割り当てるには、次の手順を実行します。**

1. 左のナビゲーションペインで、[**仮想マシン**] を選択します。

1. [**割り当て**]、[**グループ割り当ての作成**] の順に選択します。

1. 「**リソース割り当て名**」を入力します。

1. リソース割り当て [**IAM ロール**] をクリックして、バックアップを作成し、リカバリーポイントを管理します。使用する特定の IAM ロールがない場合は、正しいアクセス権限を持つ**デフォルトロール**を推奨します。

1. [**リソースグループ**] セクションで、[**Group type**] ドロップダウンメニューを選択します。選択肢は、[**フォルダ**] または [**ハイパーバイザー**] です。

   1. [**フォルダ**] をクリックして、ハイパーバイザー上のフォルダ内のすべての仮想マシンを割り当てます。[`datacenter/vm`] などの [**グループ名**] フォルダをクリックし、ドロップダウンメニューを使用します。[**サブフォルダ**] を含めることもできます。
**注記**  
フォルダベースの割り当てを行うには、検出プロセス中に、 は仮想マシンに検出プロセス中に見つかったフォルダを AWS Backup タグ付けします。後で仮想マシンを別のフォルダに移動すると、 AWS Backup AWS はタグ付けのベストプラクティスのためにタグを更新できません。この割り当て方法では、割り当てられたフォルダから移動した仮想マシンのバックアップが引き続き作成される可能性があります。

   1. [**ハイパーバイザー**] をクリックして、ハイパーバイザーによって管理されているすべての仮想マシンを割り当てます。ドロップダウンメニューを使用して、ハイパーバイザー ID [**グループ名**] を選択します。

1. [**バックアップ計画**] セクションで、ドロップダウンリストから既存の**バックアップ計画**を選択します。または、[**バックアッププランの作成**] の順にクリックして、新しいバックアッププランを作成します。

1. **グループ割り当ての作成**を選択します。

1. オプション: [**Backup プランの表示**] を選択して、仮想マシンがバックアッププランに割り当てられていることを確認します。[**リソースの割り当て**] セクションで、リソースの割り当ての [**名前**] を選択します。

**次のステップ**

仮想マシンを復元するには、「[を使用した仮想マシンの復元 AWS Backup](restoring-vm.md)」を参照してください。

# Backup ゲートウェイのサードパーティソースコンポーネントに関する情報
<a name="bgw-third-party-source"></a>

このセクションでは、バックアップゲートウェイ 機能を提供するために依存しているサードパーティー製のツールとライセンスについて情報を見つけることができます。

バックアップゲートウェイソフトウェアに含まれている、特定のサードパーティーソースソフトウェアコンポーネントのソースコードは、以下の場所からダウンロードできます。
+ VMware ESXi にデプロイされたゲートウェイの場合は、[sources.tgz](https://s3.amazonaws.com/aws-storage-gateway-terms/bgw_backup_vm/third-party-sources.tgz) をダウンロードします。

この製品には、OpenSSL Toolkit ([https://www.openssl.org/](https://www.openssl.org/)) で使用するために OpenSSL プロジェクトによって開発されたソフトウェアが含まれています。

この製品には、VMware® vSphere ソフトウェア開発キット ([https://www.vmware.com](https://www.vmware.com))。

依存するすべてのサードパーティー製ツールの関連ライセンスについては、[サードパーティーのライセンス](https://s3.amazonaws.com/aws-storage-gateway-terms/bgw_backup_vm/third-party-licenses.txt)を参照してください。

## AWS アプライアンスのオープンソースコンポーネント
<a name="aws-appliance-open-source"></a>

バックアップゲートウェイの機能を提供するために、いくつかのサードパーティ製ツールとライセンスが使用されます。

アプライアンスソフトウェアに含まれている特定のオープンソース AWS ソフトウェアコンポーネントのソースコードをダウンロードするには、次のリンクを使用します。
+ VMware ESXi にデプロイされたゲートウェイの場合は、[sources.tar](https://s3.amazonaws.com/aws-storage-gateway-terms/sources.tar) をダウンロードします。

この製品には、OpenSSL Toolkit ([https://www.openssl.org/](https://www.openssl.org)) で使用するために OpenSSL プロジェクトによって開発されたソフトウェアが含まれています。依存するすべてのサードパーティ製ツールの関連ライセンスについては、[サードパーティのライセンス](https://s3.amazonaws.com/aws-storage-gateway-terms/THIRD_PARTY_LICENSES.txt)を参照してください。

# VM 問題のトラブルシューティング
<a name="vm-troubleshooting"></a>

## 増分バックアップ/CBT の問題とメッセージ
<a name="w2aac17c19c43c27b3"></a>

**障害メッセージ:** `"The VMware Change Block Tracking (CBT) data was invalid during this backup, but the incremental backup was successfully completed with our proprietary change detection mechanism."`

このメッセージが続く場合は、VMware の指示に従って [CBT をリセット](https://knowledge.broadcom.com/external/article?legacyId=1020128)します。

**次のメッセージで、CBT がオンになっていなかったか、使用できなかったことが通知されます:***「この仮想マシンでは VMware 変更ブロック追跡 (CBT) を使用できませんでしたが、増分バックアップは当社独自の変更メカニズムで正常に完了しました。」*

CBT がオンになっていることを確認します。仮想ディスクで CBT が有効になっているかどうかを確認するには:

1. vSphere クライアントを開き、パワーオフ状態の仮想マシンを選択します。

1. 仮想マシンを右クリックして、**[設定の編集]** > **[オプション]** > **[詳細/一般]** > **[設定パラメータ]** に移動します。

1. オプション `ctkEnabled` は、`True` と等しくなければなりません。

オンになっている場合は、最新の VMware 機能を使用していることを確認してください。ホストは ESXi 4.0 以降で、追跡対象のディスクを所有する仮想マシンはハードウェアバージョン 7 以降である必要があります。

CBT がオン (有効) になっていて、ソフトウェアとハードウェアが最新の場合は、仮想マシンをオフにしてから再びオンにします。CBT がオンになっていることを確認します。次に、バックアップをもう一度実行します。

## VMware バックアップの失敗
<a name="w2aac17c19c43c27b5"></a>

VMware バックアップが失敗した場合は、次のいずれかに関連している可能性があります。

**障害メッセージ:** `"Failed to process backup data. Aborted backup job."` または `"Error opening disk on the virtual machine"`。

**考えられる原因:** このエラーは、設定の問題が原因で発生するか、VMware のバージョンまたはディスクがサポートされていない可能性があります。

**対処法 1:** インフラストラクチャがゲートウェイを使用するように設定され、必要なポートがすべて開いていることを確認します。

1. [バックアップゲートウェイコンソール](https://docs.aws.amazon.com/storagegateway/latest/tgw/accessing-local-console.html#MaintenanceConsoleWindowVMware-common)にアクセスします。これは AWS Backup コンソールとは異なることに注意してください。

1. **[Backup ゲートウェイの設定]** ページで、オプション **[3]** を入力してネットワーク接続をテストします。

1. ネットワークテストが成功した場合は、「**X**」と入力します。

1. [Backup ゲートウェイの設定] ページに戻ります。

1. 「**7**」と入力してコマンドプロンプトにアクセスします。

1. ネットワーク接続を検証するには、次のコマンドを実行します。

   `ncport -d ESXi Host-p 902`

   `ncport -d ESXi Host-p 443`

**対処法 2:** [サポートされている VM](vm-backups.md#supported-vms) バージョンを使用します。

**対処法 3:** ゲートウェイアプライアンスが間違った DNS サーバーで設定されている場合、バックアップは失敗します。DNS 設定を検証するには、次の手順を完了します。

1. [バックアップゲートウェイコンソール](https://docs.aws.amazon.com/storagegateway/latest/tgw/accessing-local-console.html#MaintenanceConsoleWindowVMware-common)にアクセスします。

1. **[Backup ゲートウェイの設定]** ページで、「**2**」と入力してネットワーク設定に移動します。

1. **[ネットワーク設定]** で、「**7**」と入力して DNS 設定を表示します。

1. DNS サーバーの IP アドレスを確認します。DNS サーバーの IP アドレスが正しくない場合は、**[ネットワーク設定]** に戻るプロンプトが表示されます。

1. **[ネットワーク設定]** で、「**6**」と入力して DNS 設定を編集します。

1. DNS サーバーの正しい IP アドレスを入力します。次に、「**X**」と入力してネットワーク設定を完了します。

エラー、ネットワーク設定、接続など、ハイパーバイザーの詳細については、「[ハイパーバイザー設定の編集](working-with-hypervisors.md#edit-hypervisor)」を参照して、Amazon CloudWatch Logs と統合するようにハイパーバイザーを設定します。

## ネットワーク接続の問題によるバックアップの失敗
<a name="w2aac17c19c43c27b7"></a>

**障害メッセージ: ** `"Failed to upload backup during data ingestion. Aborted backup job."` または `"Cloud network request timed out during data ingestion"`。

**考えられる原因:** このエラーは、ネットワーク接続がデータのアップロード処理に不十分な場合に発生する可能性があります。ネットワーク帯域幅が低い場合、VM と の間のリンクが AWS Backup 混雑し、バックアップが失敗する可能性があります。

必要なネットワーク帯域幅は、VM のサイズ、VM バックアップごとに生成される増分データ、バックアップウィンドウ、復元要件など、いくつかの要因によって異なります。

**対策:** ベストプラクティスとレコメンデーションには、オンプレミス VMs接続する最小アップロード帯域幅が 1000 Mbps であることが含まれます AWS Backup。帯域幅を確認したら、バックアップジョブを再試行します。

## バックアップジョブを中止しました
<a name="w2aac17c19c43c27b9"></a>

**障害メッセージ:** `"Failed to create backup during snapshot creation. Aborted backup job."`

**考えられる原因:** ゲートウェイアプライアンスが存在する VMware ホストに問題がある可能性があります。

**対処法:** VMware ホストの設定をチェックし、問題がないか確認します。詳細については、「[ハイパーバイザー設定の編集](working-with-hypervisors.md#edit-hypervisor)」を参照してください。

## 使用可能なゲートウェイがない
<a name="w2aac17c19c43c27c11"></a>

**障害メッセージ:** `"No gateways available to work on job."`

**考えられる原因:** 接続されているすべてのゲートウェイが他のジョブでビジー状態です。各ゲートウェイには、同時ジョブ (バックアップまたは復元) は 4 つまでという制限があります。

**対処法**については、次のセクションで、ゲートウェイの数を増やす手順と、バックアッププランのウィンドウ時間を増やす手順を参照してください。

## VMware バックアップジョブの失敗
<a name="w2aac17c19c43c27c13"></a>

**障害メッセージ: **`"Abort signal detected"`

**考えられる原因:**
+ **低ネットワーク帯域幅**: ネットワーク帯域幅が不十分な場合、完了ウィンドウ内のバックアップの完了が妨げられる可能性があります。バックアップジョブで使用可能な帯域幅よりも多くの帯域幅が必要になると、障害が発生し、「中断シグナルが検出されました」エラーがトリガーされる可能性があります。
+ **Backup ゲートウェイの不十分な数**: バックアップゲートウェイの数が、設定されたすべての VM のバックアップローテーションを処理するのに十分でない場合、バックアップジョブが失敗する可能性があります。これが発生するのは、バックアップを完了するためのバックアッププランのウィンドウが短すぎるか、バックアップゲートウェイの数が不十分である場合です。
+ バックアッププランの完了ウィンドウが小さすぎます。

**対処法:**

**帯域幅を増やす:** AWS とオンプレミス環境間のネットワーク容量を増やすことを検討してください。このステップでは、バックアッププロセスにより多くの帯域幅が提供され、エラーをトリガーすることなくデータをスムーズに転送できます。を使用してオンプレミスの VMware VMs AWS をバックアップするには、少なくとも 100-Mbps の帯域幅を持つことをお勧めします AWS Backup。

バックアップゲートウェイに対して帯域幅レート制限が設定されている場合、データの流れが制限され、バックアップの失敗につながる可能性があります。十分なデータ転送容量を確保するために帯域幅レート制限を増やすと、失敗を減らすのに役立つ場合があります。この調整により、「中断シグナルが検出されました」エラーの発生を軽減できる可能性があります。詳細については、「[Backup ゲートウェイの帯域幅スロットリング](working-with-gateways.md#backup-gateway-bandwidth-throttling)」を参照してください。

**Backup ゲートウェイの数を増やす:** 1 つのバックアップゲートウェイで一度に最大 4 つのバックアップジョブと復元ジョブを処理できます。追加のジョブはキューに入れられ、バックアップ開始ウィンドウが終了するまでゲートウェイが解放されるのを待ちます。バックアップウィンドウが終了したが、キューに入れられたジョブが開始されていない場合、それらのバックアップジョブは「中断シグナルが検出されました」エラーにより失敗します。バックアップゲートウェイの数を増やして、失敗したジョブの数を減らすことができます。詳細については、「[ゲートウェイの使用](working-with-gateways.md)」を参照してください。

**バックアッププランのウィンドウ時間を増やす:** バックアッププランのバックアップウィンドウで **[次の時間以内に完了:]** を増やすことができます。詳細については、「[バックアッププランのオプションと設定](plan-options-and-configuration.md)」を参照してください。

これらの問題解決のヘルプについては、[AWS ナレッジセンター](https://repost.aws/knowledge-center/backup-troubleshoot-vmware-backups)を参照してください。

# Windows VSS バックアップの作成
<a name="windows-backups"></a>

を使用すると AWS Backup、Amazon EC2 インスタンスで実行されている VSS (ボリュームシャドウコピーサービス) 対応 Windows アプリケーションをバックアップおよび復元できます。アプリケーションに Windows VSS に登録された VSS ライターがある場合、 はそのアプリケーションと整合性のあるスナップショット AWS Backup を作成します。

他の AWS リソースの保護に使用されるのと同じマネージドバックアップサービスを使用しながら、一貫した復元を実行できます。EC2 でアプリケーション整合性の高い Windows バックアップを使用すると、従来のバックアップツールと同じ整合性設定とアプリケーション認識が得られます。

**注記**  
AWS Backup は、Amazon EC2 で実行されているリソースのアプリケーション整合性のあるバックアップのみをサポートします。特に、既存のインスタンスをバックアップから作成された新しいインスタンスに置き換えることでアプリケーションデータを復元できるバックアップシナリオのみをサポートします。Windows VSS バックアップでは、すべてのインスタンスタイプまたはアプリケーションがサポートされているわけではありません。

詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2 Windows インスタンスの VSS ベースの EBS スナップショットを作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-vss-snaps.html)」を参照してください。

Amazon EC2 を実行する VSS 対応の Windows リソースをバックアップおよび復元するには、必要な前提条件のタスクを完了するための次の手順を実行します。手順については、「*Amazon EC2 ユーザーガイド*」の「[Windows VSS ベースの EBS スナップショットを作成するための前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html)」を参照してください。

1. で SSM エージェントをダウンロード、インストール、設定します AWS Systems Manager。このステップは必須です。詳細については、「*AWS Systems Manager ユーザーガイド*」の「[Windows Server 用 EC2 インスタンスで SSM Agent を使用する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)」を参照してください。

1. Windows VSS (ボリュームシャドウコピーサービス) のバックアップを取る前に、IAM ロールに IAM ポリシーを追加し、Amazon EC2 インスタンスにロールをアタッチします。手順については、「*Amazon EC2 ユーザーガイド*」の「[IAM マネージドポリシーを使用して VSS ベースのスナップショットに対するアクセス許可を付与する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html)」を参照してください。IAM ポリシーの例については、「[の管理ポリシー AWS Backup](security-iam-awsmanpol.md)」を参照してください。

1. [ VSS コンポーネントをダウンロードして EC2 インスタンスでの Windows にインストールする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html)

1. で VSS を有効にする AWS Backup:

   1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

   1. ダッシュボードで、**オンデマンドバックアップの作成**または**バックアッププランの管理**から作成するバックアップのタイプを選択します。バックアップタイプに必要な情報を入力します。

   1. リソースを割り当てる場合は、[**EC2**] を選択します。Windows VSS バックアップは、現在 EC2 インスタンスでのみサポートされています。

   1. [**詳細設定**] セクションで、[**Windows VSS**] を選択します。これにより、アプリケーション整合性のある Windows VSS バックアップを作成できます。

   1. バックアップを作成します。

ステータスが `Completed` のバックアップジョブは、VSS 部分が成功することを保証するものではありません。VSS の組み込みはベストエフォート方式で行われます。次の手順を実行して、バックアップがアプリケーション整合性があるのか、クラッシュコンシステントであるのか、失敗しているのかを判断してください。

1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。

1. 左側のナビゲーションの **[マイアカウント]** で **[ジョブ]** をクリックします。

1. ステータスが `Completed` の場合、アプリケーション整合性がある (VSS) ジョブが成功したことを示します。

   ステータスが `Completed with issues` の場合、VSS 操作が失敗したため、クラッシュコンシステントバックアップだけが成功したことを示します。このステータスにはポップオーバーメッセージ `"Windows VSS Backup Job Error encountered, trying for regular backup"` も表示されます。

   バックアップに失敗した場合、ステータスは `Failed` になります。

1. バックアップジョブの追加の詳細を表示するには、個々のジョブをクリックします。例えば、詳細で `Windows VSS Backup attempt failed because of timeout on VSS enabled snapshot creation` が読み取られる場合があります。

ジョブが成功した Windows 以外のターゲットまたは VSS コンポーネント以外のターゲットを持つ VSS 対応バックアップは、VSS なしで Crash-consistent になります。

## サポートされていない Amazon EC2 インスタンス
<a name="unsupported-vss-instances"></a>

次の Amazon EC2 インスタンスタイプは、小規模なインスタンスであり、バックアップを正常に取得しない可能性があるため、VSS 対応の Windows バックアップではサポートされません。
+ t3.nano
+ t3.micro
+ t3a.nano
+ t3a.micro
+ t2.nano
+ t2.micro