バックアップとスナップショットの比較

バックアップは事実上、保持期限付きの自動スナップショットである。 コンソールでは、バックアップはスナップショットと同じリストに表示されます。 ブロックストレージのスナップショットとバックアップは、VPCのブロックストレージスナップショットページに一覧表示されます。 ファイル共有のスナップショットとバックアップは、各ファイル共有のスナップショットタブで確認できます。 バックアップは、ユーザーの代わりにバックアップ・ポリシーによって、どのように作成されたかによって識別される。 スナップショットとバックアップという用語は、文脈によって、ドキュメントでは同じ意味で使われている。 スナップショットとバックアップには多くの共通点があるが、いくつかの相違点もある。 次の表は、バックアップとスナップショットの比較です：

バックアップとスナップショットの比較

特長	アカウントレベルのブロックボリュームのバックアップ	エンタープライズレベルのブロックボリュームバックアップ	ブロックボリュームのスナップショット	ファイル共有スナップショット	ファイル共有バックアップ
Block Storage for VPC のブートボリュームおよびデータボリュームをバックアップします。				該当なし	該当なし
File Storage for VPC 株をバックアップ	該当なし	該当なし	該当なし
スナップショットからボリュームまたは共有全体を手動でリストアします。
スナップショットから単一のファイルを手動で復元する	該当なし	該当なし	該当なし
スケジュールによるデータのバックアップ。			いいえ	いいえ
データを即時にバックアップします。	いいえ	いいえ			いいえ
データは特定の時点のものがコピーされます。
自動削除のための保存期間を設定します。			いいえ	いいえ
1ボリューム¹または1共有につき最大750スナップショットを取得。
高速リストア・クローン				サポートされていません	サポートされていません
地域間コピー				サポートされていません	サポートされていません
マルチボリューム整合性グループ				該当なし	該当なし
料金は月あたりのGB数に基づいて算出されます。

第一世代ストレージボリュームのスナップショットは750個、第二世代ストレージボリュームのスナップショットは512個です。

バックアップを作成する利点

VPC向け IBM Cloud バックアップには、次のようなメリットがあります。

• データ損失の防止 - 定期的なバックアップをスケジュールすることで、重要なデータを保護します。 侵害を受けたボリュームや共有を迅速に復旧するためのデータ復旧計画を策定してください。 計画外の停止による技術的および財務的な影響を軽減します。

• 小規模障害からの保護-ホスト障害または悪意のある攻撃が発生した場合に、ブート可能スナップショットからブート・ボリュームを復元します。

• コンプライアンスの向上-バックアップが実施され、データを簡単にリストアできるようにすることで、コンプライアンスと規制要件に関連する問題を防止できます。

• コストの節約-バックアップ・ポリシー保存計画は、バックアップが定期的に削除されることを意味し、必要以上のデータを保管しないことでコストを削減します。

• 管理の容易さ - IBM のバックアップサービスは、お客様の VPC リソースと完全に統合されているため、サードパーティ製のバックアップサービスよりも管理が容易です。

バックアップ・ポリシーとバックアップ計画

バックアップ・ポリシーは、ターゲット・リソース・タイプを識別し、バックアップするリソースを識別するために使用されるタグをリストします。 ポリシーには、自動バックアップ作成およびデータ保存のスケジュールを定義する 1 つ以上のバックアップ計画が含まれています。

バックアップ計画では、バックアップの頻度を設定します。 コンソールでは、毎日、毎週、毎月を選択できる。 あるいは、 cron 式を使用して頻度を指定することもできます。

バックアップ計画では、バックアップの頻度を設定します。 CLI からプランを作成するときに、 cron 式を使用して頻度を指定できます。

バックアップ計画では、バックアップの頻度を設定します。 API を使用してプランを作成する場合、 cron 式を使用して頻度を指定できます。

バックアップ計画では、バックアップの頻度を設定します。 Terraform を使用してプランを作成するときに、 cron 式を使用して頻度を指定できます。

保存期間、または最も古いバックアップが削除されるまでのバックアップの総数を指定できます。 バックアップの作成間隔とその保存期間は、同じでもよいし、異なっていてもよい。 デフォルトの保存期間は30日間ですが、保存期間の値を1日から1000日の間で設定することができます。 また、保持するバックアップの総数を、第一世代ボリュームごとに750個まで設定することもできます。 第二世代ボリュームのバックアップスナップショットの最大数は512である。 最大数を超えると、最も古いバックアップが削除される。

バックアップの存続期間と数の両方を指定すると、スナップショットを削除するタイミングを決定する際に存続期間が優先されます。 このカウントは、最も古いスナップショットが存続期間の範囲内にある場合にのみ適用されます。

以下の例を考えてみます。

• 例 1-保存期間が 14 日で、保持するスナップショットの最大数がない日次計画を作成します。 14 個のバックアップを保持する予定で、最も古いバックアップは 2 週間前になります。
• 例2 - 週間プランを作成し、保存期間を365日、最大カウント数を8とします。 実際には、チェーン内で最大 8 つのスナップショットを取得することになります。最も古いスナップショットは 8 週間前です。
• 例 2-月次プランを作成し、最大カウント 10 で 80 日の保存期間を設定します。 実際には、常に最大 3 つのスナップショットを保持します。 4回目のバックアップが取られる頃には、1回目のバックアップは80日という節目を迎え、削除されてしまう。

バックアップポリシーごとに最大4つのプランを作成でき、バックアップのスケジュールや保存期間ポリシーはいつでも変更可能です。 4 つの計画は、異なる頻度を持つことができます。 例えば、日次にすることができます。 もう 1 つは、週に 1 回、または月に 1 回です。 すべてのプランは、バックアップ・ポリシーに一致するタグを持つボリュームに適用されます。 バックアッププランによって作成されたバックアップは、親となるボリュームリソースグループの詳細を引き継ぎます。

バックアップの作成、変更、削除が行われている間、 バックアップジョブのステータスを確認できます。

バックアップ・プランやバックアップ・ポリシーは、不要になったら削除することができます。 バックアップポリシーを削除すると、それに関連するすべてのプランも削除されます。 バックアッププランを削除または無効にすると、そのプランはバックアップジョブを開始できなくなります。 バックアップスナップショットの作成や削除は一切行われなくなった。 既存のバックアップは、そのライフサイクルがポリシーから独立しているため、そのまま残ります。 既存のバックアップは別途削除する必要がある。

バックアップ・ポリシーの有効範囲

エンタープライズ・アカウント管理者は、エンタープライズ・アカウントの下の子アカウント全体でまとめてバックアップ・プランとポリシーを管理できます。 エンタープライズ・アカウント・ユーザーは、エンタープライズ・アカウントによって作成されたすべてのバックアップ・ポリシーを表示できます。 エンタープライズ・アカウント・ユーザーは、ジョブが子アカウントで実行される場合でも、エンタープライズ・バックアップ・ポリシーによって開始されるすべてのバックアップ・ジョブを表示できます。

エンタープライズ内の各アカウント内のユーザーは、スタンドアロン・アカウントで行えるのと同様に、リソースの作成、使用、およびコラボレーションを行うことができます。 詳しくは、 エンタープライズ内のリソースの処理 を参照してください。

エンタープライズ管理者には、ポリシーによって作成されたすべてのバックアップ・スナップショットの参照が表示されますが、子アカウントには、そのアカウントで作成されたバックアップのみが表示されます。

子アカウントのユーザーは、エンタープライズ・レベルのポリシーによって自分のアカウントで作成されたバックアップ・スナップショットを表示できます。 これらのバックアップは、バックアップを作成したエンタープライズ・レベルのバックアップ・ポリシーの CRN によって識別できます。 ただし、エンタープライズ・レベルのバックアップ・ポリシー自体に対する可視性はありません。 子アカウントのユーザーは、バックアップを使用して他のボリュームを作成できます。

子アカウントの許可ユーザーは、自分のアカウントにアカウント固有のバックアップ・ポリシーを作成することもできます。

ターゲット・リソースのタグ

バックアップ ポリシーには、同じユーザ タグを持つブロック ストレージ ボリューム、ファイル共有、または仮想サーバ インスタンスにポリシーを関連付けるターゲット リソースのユーザ タグが含まれています。 バックアップを作成するには、リソースに適用される少なくとも 1 つのユーザー・タグが、バックアップ・ポリシー内のタグと一致している必要があります。 ユーザー・タグは、アカウント内の許可ユーザーによって追加されます。 適切なアクセス役割を持つユーザーは、タグがどのリソースにも付加されていないという条件で、アカウント内のユーザー・タグをリストおよび削除できます。

ユーザー・タグに加えて、タグはアクセス管理タグおよびサービス・タグにすることができます。 ユーザー・タグのみがバックアップ・ポリシーに適用されます。 アクセス管理タグ は、リソースへのアクセスを管理するために使用されます。アクセス管理タグを作成できるのは、アカウント管理者のみです。 サービス・タグは、許可されたサービスのみが管理できる特権構成体です。 ユーザーは、リソース上のタグを管理するためのアクセス権限を持っている場合でも、リソースに対するサービス・タグの付加と切り離しを行う権限がありません。 サービス・タグは、バックアップ・ポリシーによって手動または自動で作成されたスナップショットを区別するのに役立ちます。

ボリューム、共有、または仮想サーバーインスタンスに複数のタグがある場合、1 つのタグのみがバックアップポリシータグと一致する必要があります。 バックアップ計画のスケジュールに基づいて、一致するタグによってバックアップがトリガーされます。 バックアップポリシーのタグに一致するタグが複数ある場合、スケジュールされた間隔で作成されるバックアップは1つだけです。 同じタグを持つリソースが複数ある場合、一致するすべてのリソースに対してバックアップが作成されます。

リソースに対して最大 1,000 個のユーザー・タグを追加できます。 ただし、同じ操作で接続または切り離すことができるタグは 100 個のみです。 タグの数を少なくしておくと、作成しているバックアップの数を追跡しやすくなります。 詳しくは、 タグ付きのリソースへのバックアップ・ポリシーの適用 を参照してください。

ターゲット・リソースに使用するタグを決定する場合は、他のポリシーが既に同じタグを使用していないことを確認してください。

バックアップからボリュームまたは共有をリストアする

バックアップスナップショットから別のボリュームまたは共有を作成できます。 このプロセスは「復元」と呼ばれます。 これは、手動で作成したスナップショットからデータを復元する場合と同じ仕組みです。 バックアップスナップショットからボリュームを復元すると、完全にプロビジョニングされた Block Storage for VPC のブートボリュームまたはデータボリュームが作成されます。

ボリュームは、インスタンスの作成時、インスタンスの変更時、またはスタンドアロン・ボリュームの作成時にリストアできます。 ボリューム・データのリストアは、ボリュームがハイドレートされると即時に開始されますが、ボリュームが完全にリストアされるまでは パフォーマンスが低下します。 ブート可能スナップショットからのリストアは、通常のブート・ボリュームを使用する場合より遅くなります。

復元されたボリュームは、元のボリュームと同じ容量とボリュームプロファイルを持っています。 詳細については、「 バックアップスナップショットからボリュームを復元する 」を参照してください。

スナップショット整合性グループ ID からの仮想サーバー・インスタンスの直接リストアはサポートされていません。 ただし、整合性グループの一部であるスナップショットからすべてのブート・ボリュームおよびデータ・ボリュームをリストアすることで、仮想サーバー・インスタンスをリストアすることができます。

ファイル共有のバックアップは、新しい共有の作成にも使用できる。 スナップショットはファイル共有とコロケートされているため、初期化中に新しい共有のパフォーマンスが影響を受けることはありません。 しかし同じ理由で、ファイル共有のバックアップは、それ自体を別のリージョンやゾーンにコピーして新しい共有を作成することはできない。 詳細については、 スナップショットからの共有の復元 を参照してください。

第1世代のボリュームまたは共有のスナップショットを使用して、第2世代のボリュームまたは共有を作成することはできません。 同様に、第2世代のボリュームまたは共有からのスナップショットを使用して、第1世代のプロファイルでブロックボリュームまたはファイル共有を作成することはできません。

高速リストアを使用したボリュームのリストア

高速リストアを使用してブロック・ストレージ・ボリュームをリストアすると、完全に消火栓されたボリュームが作成されます。

高速リストア・ゾーンを使用して バックアップ・ポリシー計画 を作成し、必要に応じて後でゾーンを追加または削除することができます。 高速リストア機能は、バックアップ・スナップショットの 1 つ以上のコピーを、選択したゾーンにキャッシュします。 後で、これらのバックアップ・クローンを使用して、同じリージョン内の任意のゾーンにボリュームを作成できます。

詳細については、「 バックアップスナップショットからボリュームを復元する 」を参照してください。

地域間バックアップ・コピー

あるリージョンから別のリージョンにブロック・ストレージ・バックアップをコピーし、後でそのスナップショットを使用して新しいリージョンにボリュームをリストアすることができます。 ターゲット領域内のクロス地域スナップショットは、親ボリュームまたは元のスナップショットとは独立して使用および管理できます。

ソース・スナップショットがカスタマー・キーで暗号化されていない場合、コピーの暗号化はプロバイダー管理のままになります。 お客様スナップショットが顧客管理キーによって保護されている場合、ターゲットリージョンで新しいコピーを暗号化するためにお客様キーを指定する必要があります。

バックアップポリシーがクロスリージョナルコピーを含むジョブを作成する場合、サービスはまずバックアップスナップショットの作成を開始します。 スナップショットの作成は非同期です。 スナップショットは即座に作成されますが、すべてのデータがリージョナルストレージリポジトリに転送されるまで_保留_状態のままとなります。 スナップショットがソース領域で_安定した_状態に達すると、サービスはターゲット領域にコピーを作成し、データの転送を開始します。

ボリュームの容量が多いほど、別のリージョンにスナップショットコピーを作成するのに時間がかかります。 例えば、3TBのストレージボリュームのコピーをリモートリージョンに作成する場合、 12.5 時間以上かかる。

バックアップスナップショットのリモートコピーを初めて作成する場合、そのリモートコピーには親ボリュームのすべてのデータが含まれます。 その後のコピーは、インクリメンタルコピーでもフルコピーでもよい。 リモートコピーがインクリメンタルかどうかは、チェーンの直前のバックアップスナップショットに依存します。 直前のスナップショットがデスティネーション領域に存在する場合、コピーはインクリメンタルになる。 直前のスナップショットが存在しないか、安定していない場合、新しいコピーは親ボリュームの完全なスナップショットでなければなりません。

バックアップ計画で、前のバックアップコピーが安定する前にリモートコピーを作成するよう求めている場合、バックアップサービスは増分コピーではなく完全コピーを開始します。 3 TBのボリュームの場合、スナップショットをリモートリージョンにコピーするには、完了までに12時間以上かかることがあります。 12時間ごとにスケジュールされたスナップショットは、前回のリモートコピーがまだ完了しておらず、安定した状態になっていないため、フルコピーが実行されることになります。

次の表は、ボリューム容量（スナップショットサイズ）とバックアップ頻度に基づいて、リモートコピーがインクリメンタルになるかどうかを示しています。

各リージョンに存在できるバックアップ・スナップショットのコピーは 1 つのみです。 ソース (ローカル) リージョンにバックアップ・スナップショットのコピーを作成することはできません。

地域間コピーを作成すると、請求に影響します。 ターゲット領域でのデータ転送とストレージ使用量に対して個別に課金されます。

バックアップポリシー用のIAMロール

バックアップを行うには、役割ベースのアクセス制御のための IAM 権限が必要です。 バックアップユーザーとして割り当てられた役割に応じて、バックアップポリシーを作成および管理することができます。 詳細については、 VPC 向けリージョン別バックアップ サービスにおける IAM ロールとアクション。

詳しくは、アクセス権限を割り当てるためのベスト・プラクティスを参照してください。 アカウントへのユーザーの招待や Cloud IAM アクセス権限の割り当てを含め、IAM プロセス全体については、IAM 入門チュートリアルを参照してください。

サービス間の許可

サービス間の許可を付与するには、特定の IAM ユーザー役割が必要です。 バックアップサービスとCloud Block Storage、VPC用スナップショット、VPC用仮想サーバー間のサービス間認証が必要となります。これにより、バックアップサービスがボリュームタグを検出し、スナップショットを作成できるようになります。 ファイル共有の自動スナップショットを作成する場合は、Backupサービスと Cloud File Storage サービスの間でサービス間認証を設定します。 詳細については 、「サービス間接続の承認の確立 」を参照してください。

サービス間認証を設定する際は、認証スコープがバックアップが必要なすべてのリソースを網羅していることを確認してください。 リソース固有のIAMポリシーを使用する場合は、ボリュームのバックアップが必要なすべての仮想サーバーインスタンスが、承認範囲に含まれていることを確認してください。 バックアップポリシーの作成プロセスでは、適用範囲が狭すぎる承認ポリシーを検出できないため、承認範囲外のリソースに対して、何の前触れもなくバックアップが失敗する可能性があります。 バックアップジョブのステータスを定期的に監視し、権限に関する問題を早期に発見するようにしてください。 詳細については、「 バックアップジョブのステータスの確認 」を参照してください。

タグを適用して後でバックアップ対象に追加するリソースがある場合、そのリソースに固有の権限設定があるときは、権限設定を見直し、新しいリソースが対象に含まれるよう調整してください。 リソース固有の権限の適用範囲が、新たにタグ付けされたリソースをカバーしていない場合、新しいバックアップが失敗する可能性があります。

コンテキスト・ベースの制約事項

すべてのブロック・ボリュームとファイル共有操作に対して、コンテキスト・ベースの制限（CBR）を有効にできます。 これらの制限は、ID に基づく従来の IAM ポリシーと連携して、追加の保護レイヤーを提供します。 詳細については、 コンテキストベースの制限による仮想プライベートクラウド（VPC）インフラストラクチャサービスの保護を 参照してください。

コンテキスト・ベースのルールを 作成する際には、プライベート・エンドポイントを許可するようにしてください。 バックアップ・サービスが機能するために必要なサービス間の接続は、すべてプライベートなものだ。

静止時と転送時の暗号化

バックアップスナップショットは、親ボリュームまたは共有と同じ暗号化タイプおよび暗号化キーを持ちます（顧客管理またはプロバイダ管理）。

ボリューム・バックアップは、地域ストレージ・リポジトリに保存され、そこから取得される。 データは転送中に暗号化され、元のボリュームと同じリージョンに保管されます。

アクティビティ追跡と監査

バックアップが作成されると、 Backup サービスと Snapshots サービスのイベントがトリガーされます。 同様に、認可がないためにサービスがバックアップの作成に失敗すると、イベントがトリガーされて通知されます。 イベントログは、バックアップポリシーやプランが作成または削除されたときにも作成されます。 詳しくは、 IBM Cloud VPC のアクティビティ追跡 イベントをご覧ください。