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

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

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

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

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

IBM Cloud Backup for VPCには以下のようなメリットがあります。

• データ損失の防止 - 定期的なバックアップをスケジュールすることで、重要なデータを保護します。 危殆化したボリュームまたは共有を迅速にリストアするために、データ・リストア・プランを確立する。 計画外の停止による技術的および財務的な影響を軽減します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

バックアップの作成、変更、または削除中に バックアップジョブのステータスを表示 できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

バックアップポリシーがクロスリージョナルコピーを含むジョブを作成すると、サービスはターゲットリージョンにコピーを作成する要求を開始するのを待ちます。 サービスは、ソーススナップショットが_安定_状態に達した後にコピーを作成し始める。

バックアップスナップショットのリモートコピーを初めて作成する場合、そのリモートコピーには親ボリュームのすべてのデータが含まれます。 その後のコピーは、インクリメンタルコピーでもフルコピーでもよい。

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

バックアップ計画で、前のバックアップコピーが安定する前にリモートコピーを作成するよう求めている場合、バックアップサービスは増分コピーではなく完全コピーを開始します。

ボリュームの容量が多いほど、別のリージョンにスナップショットコピーを作成するのに時間がかかります。 例えば、3TBのストレージボリュームのコピーをリモートリージョンに作成する場合、 12.5 時間以上かかる。 したがって、スケジュールで12時間ごとにリモートコピーによるスナップショットの作成を指定した場合、前回のコピーがまだ完全で完全に安定していないため、システムはフルコピーを開始します。

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

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

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

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

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

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

サービス間の許可

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

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

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

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

静止時と転送時の暗号化

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

ボリュームのバックアップは、 IBM Cloud® Object Storage から保存および取得されます。 データは転送中に暗号化され、元のボリュームと同じリージョンに保管されます。

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

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