翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# スナップショットと AMI による Amazon EC2 のバックアップとリカバリ
Amazon マシンイメージ (AMI) を使って EC2 インスタンスのフルバックアップを作成する必要があるのか、それとも個々のボリュームのスナップショットを取る必要があるのかを検討します。
## バックアップには AMI または Amazon EBS スナップショットを使用する
AMI には以下のものが含まれています。
+ 1 つ以上のスナップショット。インスタンスストアバックアップされた AMI には、インスタンスのルートボリュームのテンプレート (例えば、オペレーティングシステム、アプリケーションサーバー、アプリケーション) が含まれます。
+ AMI を使用してインスタンスを起動できる AWS アカウントを制御する起動許可。
+ インスタンスの起動時にインスタンスにアタッチするボリュームを指定するブロックデバイスマッピング
**注記**
ほとんどの場合、Windows、RedHat、SUSE、SQL Server の AMI には、正しいライセンス情報が存在する必要があります。詳細については、「[AMI 請求情報の理解](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html)」を参照してください。スナップショットから AMI を作成する場合、`RegisterImage` オペレーションはスナップショットのメタデータから正しい請求情報を取得しますが、これには適切なメタデータが必要です。正しい請求情報が適用されたかどうかを確認するには、新しい AMI の **[プラットフォームの詳細]** フィールドを確認します。フィールドが空であるか、所定のオペレーティングシステムコード (Windows、RedHat、SUSE、SQL など) と一致しない場合、AMI の作成は失敗しているため、この AMI を破棄して「[インスタンスから AMI を作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami)」の手順に従う必要があります。
AMI を使用して、事前設定されたソフトウェアとデータを使用して新しいインスタンスを起動できます。AMI は、ベースラインを設定したいときに作成できます。ベースラインとは、より多くのインスタンスを起動するための再利用可能な設定です。既存の EC2 インスタンスの AMI を作成すると、インスタンスにアタッチされているすべてのボリュームのスナップショットが取得されます。スナップショットにはデバイスマッピングが含まれます。
スナップショットを使用して新しいインスタンスを起動することはできませんが、既存のインスタンス上のボリュームを置き換えるために使用できます。データの破損やボリューム障害が発生した場合は、撮影したスナップショットからボリュームを作成し、古いボリュームを置き換えることができます。スナップショットを使用して新しいボリュームをプロビジョニングし、新しいインスタンスの起動時にアタッチすることもできます。
によって AWS 、または から管理および公開されているプラットフォームおよびアプリケーション AMIs を使用している場合は AWS Marketplace、データ用に個別のボリュームを維持することを検討してください。データボリュームは、オペレーティングシステムやアプリケーションボリュームとは別のスナップショットとしてバックアップできます。次に、 によって、 AWS または から発行された新しく更新された AMIs で、データボリュームスナップショットを使用します AWS Marketplace。このアプローチでは、設定情報を含むすべてのカスタムデータを、新しく公開した AMI にバックアップして復元するための綿密なテストと計画が必要です。
復元プロセスは、AMI バックアップとスナップショットバックアップのどちらを選択したかに影響されます。インスタンスのバックアップとして機能する AMI を作成する場合、復元プロセスの一環として AMI から EC2 インスタンスを起動する必要があります。衝突の可能性を避けるため、既存のインスタンスをシャットダウンする必要がある場合もあります。衝突の可能性がある例としては、ドメインに参加している Windows インスタンスのセキュリティ識別子 (SID) があります。スナップショットの復元プロセスでは、既存のボリュームをデタッチし、新しく復元したボリュームをアタッチする必要がある場合があります。または、アプリケーションが新しくアタッチされたボリュームを参照するように設定を変更する必要がある場合もあります。
AWS Backup は、インスタンスレベルのバックアップを AMIs としてサポートし、ボリュームレベルのバックアップを個別のスナップショットとしてサポートします。
+ インスタンス上のすべての EBS ボリュームの完全なバックアップを行うには、[EC2 インスタンスの AMI を作成します](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html)。ロールバックする場合は、インスタンス起動ウィザードを使用してインスタンスを作成します。インスタンス起動ウィザードで、[**マイ AMI**] を選択します。
+ 個々のボリュームをバックアップするには、[スナップショットを作成します](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html)。スナップショットを復元するには、「[スナップショットからボリュームを作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot)」を参照してください。または AWS Command Line Interface () を使用できます AWS マネジメントコンソール AWS CLI。
インスタンス AMI のコストは、インスタンス上のすべてのボリュームのストレージですが、メタデータのストレージではありません。EBS スナップショットのコストは、個々のボリュームのストレージです。ボリュームストレージのコストの詳細については、[Amazon EBS の料金のページ](https://aws.amazon.com/ebs/pricing/)を参照してください。
## サーバーボリューム
EBS ボリュームは、Amazon EC2 の主要な永続ストレージオプションです。このブロックストレージは、データベースなどの構造化データや、ボリューム上のファイルシステム内のファイルなどの非構造化データに使用できます。
EBS ボリュームは特定のアベイラビリティーゾーンに置かれます。ボリュームは複数のサーバーにレプリケートされ、単一のコンポーネントの障害によるデータの損失を防ぎます。故障とは、ボリュームのサイズと性能に応じて、ボリュームの完全または部分的な喪失を指します。
EBS ボリュームは、年間故障率 (AFR) が 0.1 ～ 0.2% になるように設計されています。これにより、EBS ボリュームの信頼性が、約 4% の AFR で故障する一般的なコモディティディスクドライブに比べて EBS ボリュームの信頼性が 20 倍に高まります。例えば、1,000 個の EBS ボリュームを 1 年間稼動させる場合、1 個か 2 個のボリュームに障害が発生することを想定しておく必要があります。
Amazon EBS は、データのポイントインタイムバックアップを取るためのスナップショット機能もサポートしています。すべての EBS ボリュームタイプは、耐久性のあるスナップショット機能を提供し、99.999% の可用性を実現するように設計されています。詳細については、[「Amazon Compute サービスレベルアグリーメント」](https://aws.amazon.com/ec2/sla/)を参照してください。
Amazon EBS は、あらゆる EBS ボリュームのスナップショット (バックアップ) を作成する機能を提供しています。スナップショットは、EBS ボリュームのバックアップを作成するための基本機能です。スナップショットは EBS ボリュームのコピーを取り、Amazon S3 に置き、複数のアベイラビリティーゾーンに冗長的に保存されます。最初のスナップショットはボリュームの完全コピーであり、進行中のスナップショットはブロックレベルの増分変更のみを保存します。Amazon EBS スナップショットの作成方法の詳細については、[Amazon EBS のドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html)を参照してください。
スナップショットを取得したのと同じリージョンで、[Amazon EC2コンソールから](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html)スナップショットに関連付けられたリストア操作、スナップショットの削除、タグなどのスナップショットメタデータの更新を実行できます。
スナップショットをリストアすると、フルボリュームのデータを持つ新しい Amazon EBS ボリュームが作成されます。部分的な復元のみが必要な場合は、実行中のインスタンスに別のデバイス名でボリュームをアタッチできます。次にそれをマウントし、オペレーティングシステムのコピーコマンドを使って、バックアップボリュームから本番ボリュームにデータをコピーします。
Amazon EBS スナップショットは、Amazon EBS [ドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html)で説明されているように、Amazon EBS スナップショットコピー機能を使用して AWS リージョン間でコピーすることもできます。この機能を使用すると、基盤となるレプリケーションテクノロジーを管理しなくても、バックアップを別のリージョンに保存できます。
## 個別のサーバーボリュームを確立する
オペレーティングシステム、ログ、アプリケーション、およびデータには、すでに標準の個別のボリュームセットを使用している場合があります。個別のサーバーボリュームを確立することで、ディスクスペースの枯渇が原因でアプリケーションやプラットフォームに障害が発生した場合の影響範囲を軽減できます。通常、物理ハードドライブで物理的なハードディスクドライブの場合、ボリュームを迅速に拡張する柔軟性がないため、このリスクは通常より大きくなります。物理ドライブの場合は、新しいドライブを購入してデータをバックアップし、新しいドライブにデータを復元する必要があります。を使用すると AWS、Amazon EBS を使用してプロビジョニングされたボリュームを拡張できるため、このリスクが大幅に軽減されます。詳細については、[「AWS ドキュメント」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-volume-requirements.html)を参照してください。
アプリケーションデータ、ユーザーデータ、ログ、スワップファイル用に別々のボリュームを用意して、これらのリソースに別々のバックアップポリシーと復元ポリシーを使用できるようにします。データ用にボリュームを分けることで、データのパフォーマンスとストレージの要件に基づいて異なるボリュームタイプを使用することもできます。そして、異なるワークロードに対してコストを最適化し、ファインチューニングできます。
## インスタンスストアボリュームに関する考慮事項
*インスタンスストア*は、インスタンス用のブロックレベルの一時ストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。インスタンスストアは、バッファ、キャッシュ、スクラッチデータ、その他の一時的なコンテンツなど、頻繁に変更される情報の一時的な保存に最適です。また、ウェブサーバーのロードバランストプールなど、複数のインスタンスにまたがってレプリケートされるデータにも適しています。
インスタンスストア上のデータは、関連付けられたインスタンスの運用中のみ維持されます。インスタンスが再ブートされた場合、その再ブートが意図的なものでも、意図せずに行われたとしても、インスタンスストアのデータは維持されます。ただし、次のいずれの状況でも、インスタンスストアのデータは失われます。
+ 基盤となるドライブが故障しました。
+ インスタンスが停止しました。
+ インスタンスが終了します。
したがって、価値のある長期的なデータをインスタンスストアに依存してはなりません。代わりに、Amazon S3、Amazon EBS、または Amazon EFS などのより堅牢なデータストレージを使用してください。
インスタンスストアボリュームの一般的な戦略は、目標復旧時点 (RPO) と目標復旧時間 (RTO) に基づいて、必要に応じて必要なデータを定期的に Amazon S3 に永続化することです。その後、新しいインスタンスが起動されたときに、Amazon S3 からインスタンスストアにデータをダウンロードできます。インスタンスが停止する前に、Amazon S3 にデータをアップロードすることもできます。永続化のため、EBS ボリュームを作成してインスタンスにアタッチし、そのデータをインスタンスストアボリュームから EBS ボリュームに定期的にコピーします。詳細については、「[AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/back-up-instance-store-ebs/)」 を参照してください。
## EBS スナップショットと AMI のタグ付けと標準の適用
すべての AWS リソースにタグを付けることは、コスト配分、監査、トラブルシューティング、通知のための重要なプラクティスです。EBS ボリュームでは、ボリュームの管理と復元に必要な関連情報が表示されるようにするためのタグ付けが重要です。タグは EC2 インスタンスから AMI に、またはソースボリュームからスナップショットに自動的にコピーされません。バックアッププロセスには、これらのソースからの関連タグが含まれていることを確認してください。これは、将来これらのバックアップを使用するために、アクセスポリシー、添付ファイル情報、コスト配分などのスナップショットメタデータを設定するのに役立ちます。 AWS リソースのタグ付けの詳細については、[「タグ付けのベストプラクティスのテクニカルペーパー](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)」を参照してください。
すべての AWS リソースに使用するタグに加えて、次のバックアップ固有のタグを使用します。
+ ソースインスタンス ID
+ ソースボリューム ID (スナップショット用)
+ 回復ポイントの説明
AWS Config ルールと IAM アクセス許可を使用して、タグ付けポリシーを適用できます。IAM は強制的なタグ使用をサポートしているため、Amazon EBS スナップショットを使用する際に特定のタグの使用を義務付ける IAM ポリシーを作成できます。IAM アクセス権限ポリシーで定義されたタグで権限を付与せずに `CreateSnapshot` 操作を試みると、スナップショットの作成はアクセスが拒否されて失敗します。詳細については、[「Amazon EBS スナップショットの作成時のタグ付けとより強力なセキュリティポリシーの実装に関するブログ記事」](https://aws.amazon.com/blogs/compute/tag-amazon-ebs-snapshots-on-creation-and-implement-stronger-security-policies/)を参照してください。
AWS Config ルールを使用して、リソースの設定を自動的に評価できます AWS 。開始しやすくするために、 はマネージドルールと呼ばれるカスタマイズ可能な事前定義されたルール AWS Config を提供します。独自のカスタムルールを作成することもできます。はリソース間の設定変更 AWS Config を継続的に追跡しながら、これらの変更がルールの条件に違反していないかどうかを確認します。リソースがルールに違反した場合、 はリソースとルールを*非準拠*として AWS Config フラグ付けします。[「required-tags」](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html) マネージドルールは現在、スナップショットと AMI をサポートしていないことに注意してください。