ブロック・ボリューム・バックアップ

• ボリューム・バックアップのリスト
• 新しいボリュームへのバックアップのリストア
• リージョン間でのボリューム・バックアップのコピー
• 別のコンパートメントへのブロック・ボリューム・バックアップの移動
• ボリューム・バックアップの削除

ボリュームの手動バックアップおよびポリシーベースのバックアップ(バックアップ・ポリシー)も参照してください。

ボリューム・バックアップを開始するには、管理者がIAMポリシーを介してユーザー・アクセス権を付与する必要があります。Oracle Cloud Infrastructureの各サービスは、すべてのインタフェース(コンソール、SDKまたはCLI、およびREST API)の認証および認可のためにIAMと統合されています。

ブロック・ボリューム管理者がリージョン間でブロック・ボリューム、バックアップおよびボリューム・グループを管理できるようにするポリシーの例:

Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy
Allow group VolumeBackupAdmins to inspect instances in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancy
Allow group VolumeBackupAdmins to use volume-backups in tenancy where request.permission='VOLUME_BACKUP_COPY'

Allow group BootVolumeBackupAdmins to use volumes in tenancy
Allow group BootVolumeBackupAdmins to manage boot-volume-backups in tenancy
Allow group BootVolumeBackupAdmins to inspect instances in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policies in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policy-assignments in tenancy
Allow group BootVolumeBackupAdmins to use boot-volume-backups in tenancy where request.permission='BOOT_VOLUME_BACKUP_COPY'

ブロック・ボリュームで使用可能なバックアップ・タイプは、次のとおりです。

• 増分: このバックアップ・タイプでは、前回のバックアップ以降の変更のみが含められます。
• 完全: このバックアップ・タイプでは、ボリュームが作成されてからのすべての変更が含められます。

例

50 GBのブロック・ボリュームを作成し、25 GBをボリュームに書き込み、2日間の保持期間で1日目にボリュームのフル・バックアップを起動します。完了すると、バックアップ・サイズは25 GBになります。

2日目には、既存のデータを2 GB変更し、新しいデータを3 GB書き込み、増分バックアップを作成します。増分バックアップの一意のサイズは合計5 GBです。

3日目には、既存のデータの3Gを変更し、新しいデータを2 GB追加した別の増分バックアップが作成され、合計5 GBになります。

4日目には、保存期間が切れると完全バックアップが削除されます。増分バックアップ・サイズの合計は28 GBになり、その内容は増分バックアップが作成された時点までボリュームの内容をリストアするために必要です。

5日目には、最初の増分バックアップ保持が期限切れになります。この2番目の増分バックアップのバックアップ・サイズは合計30 GBで、2番目の増分バックアップが作成された時点でのボリューム・コンテンツの実際のサイズです。全体バックアップの削除後もブロックは保持されるため、ボリュームは増分バックアップからリストアできます。

ボリューム・バックアップ・サイズは、現在のボリューム使用量より大きくすることができます。バックアップ・サイズが大きい原因として、次のものが考えられます。

• 書き込まれたボリュームの一部は初期化済とみなされるため、常にボリューム・バックアップに含まれます。
• 多くのオペレーティング・システムでは、これらのブロックが使用済とマークされるコンテンツを書込みまたはゼロにします。ブロック・ボリューム・サービスは、更新されたブロックを考慮し、これらのブロックをボリューム・バックアップに含めます。
• ボリューム・バックアップには、他のデータで最大1 GBのメタデータも含まれます。たとえば、256 GB Windowsブート・ディスクのフル・バックアップでは、追加の1 GBのメタデータを含む257 GBのバックアップ・サイズが表示される場合があります。

リージョン間でのブロック・ボリューム・バックアップのコピーでは、次のシナリオが拡張されます:

• ディザスタ・リカバリおよびビジネス継続性:ブロック・ボリューム・バックアップをリージョン間で定期的にコピーすると、ソース・リージョンでリージョン全体にわたる障害が発生した場合に、宛先リージョンでアプリケーションとデータを簡単に再作成できます。
• 移行と拡張: アプリケーションを別のリージョンに移行および拡張することが容易になります。

ユーザー定義ポリシーを使用して、スケジュール済リージョン間自動バックアップを有効にすることもできます。リージョン間でのボリューム・バックアップ・コピーのスケジューリングを参照してください。

ボリューム・バックアップをリージョン間でコピーするには、ソース・リージョンでボリューム・バックアップを読み取ってコピーする権限と、宛先リージョンでボリューム・バックアップを作成する権限が必要です。詳細は、リージョン間でのボリューム・バックアップのコピーを参照してください。

ボリューム・バックアップを新しいリージョンにコピーしたら、新しいボリュームへのバックアップのリストアのに示されたステップを使用して、バックアップからの新しいボリュームを作成することで、そのバックアップからのリストアを行うことができます。

Oracle Cloud Infrastructure Block Volumeサービスは、256ビット暗号化によるAdvanced Encryption Standard (AES)アルゴリズムを使用して、すべてのブロック・ボリューム、ブート・ボリューム、および保存ボリューム・バックアップを常に暗号化します。

Oracle Cloud Infrastructure Vaultサービスを使用すると、ボリュームおよびそのバックアップの暗号化に使用する独自のキーを指定して管理できます。ボリューム・バックアップを作成すると、ボリュームに使用される暗号化キーがボリューム・バックアップにも使用されます。

ボリューム・バックアップの暗号化キーは、別のVault暗号化キーまたはOracle管理キーに変更できます。詳細は、「割り当てられたマスター暗号化キーの変更」を参照してください。

バックアップをリストアして新しいボリュームを作成する場合は、新しいキーを構成します。新しいボリュームへのバックアップのリストアを参照してください。「Vault」も参照してください。

ボールト・サービスを使用するようにボリュームを構成していない場合、ブロック・ボリューム・サービスではかわりにOracle提供の暗号化キーが使用されます。これは、保存中暗号化と転送中暗号化の両方に適用されます。

リソースにタグを適用して、ビジネス・ニーズに応じてそれらを整理しやすくなります。リソースの作成時にタグを適用することも、後からリソースを更新してタグを追加、改訂または削除することもできます。タグ適用についての一般情報は、リソース・タグを参照してください。

バックアップを作成およびリストアする際には、次の点に注意してください:

• クリティカルなアプリケーション・ボリュームを毎日複数回バックアップします。ミッションクリティカルなアプリケーションの場合、リカバリ・ポイント目標(RPO)の可能性を最小限に抑えるために、1日に複数のバックアップを作成することをお薦めします。

  ノート
  
  ポリシーベースのバックアップでは、1日当たり1つのバックアップおよびコピーのみをスケジュールできます。ユーザーは、手動バックアップを使用して1日に複数のバックアップを開始できます。クロス・リージョン・コピーの場合は、1日に1つのバックアップのみをリモート・リージョンにコピーすることをお薦めします。さらに小さいRPOについては、レプリケーションサポートを確認してください。
• バックアップの保持時間および有効期限を構成します。バックアップは、ストレージ領域およびコストを解放するために設定された有効期限の後に自動的にパージされます。手動バックアップは期限切れになりません。

• オフピーク時間にバックアップをスケジュールまたは作成します。予期した時間にバックアップが完了していないことに気付いた場合は、スケジュールされたバックアップ時間または手動のバックアップ時間を別の時間に変更することを検討してください。日次バックアップは引き続き24時間以内に完了します。

• クリティカル・データと非クリティカル・データを編成します。 管理が必要なバックアップの量を減らすには、クリティカル・データおよび非クリティカル・データに対して別々の作成、バックアップおよびリカバリ操作を使用することをお薦めします。クリティカル・データには、通常、アプリケーションのリカバリおよび使用に必要なすべてのデータが含まれます。ベスト・プラクティスは、重要なデータをブート・ボリュームではなくセカンダリ・ブロック・ボリュームに保持することです。クリティカルでないデータには、スワップ、一時ファイル、キャッシュ・ファイルまたはページ・ファイルおよび非クリティカル・ログが含まれ、サイズが大きくなる傾向があります。

• ボリューム・グループを使用して、ボリューム間のクラッシュ一貫性バックアップを作成します。 データが複数のボリュームに分散している場合は、ボリューム・グループとして作成およびバックアップできます。ボリューム・グループ・バックアップでは、各ボリュームに同期されたすべてのデータが一貫して取得されるため、個別のスナップショットを取得するためにインスタンスを停止する必要がなくなりました。この方法は、ジャーナル処理をサポートするファイルシステムやアプリケーションに最適です。
• アプリケーション一貫性バックアップにより、データのリカバリ性とリカバリ時間を最大化します。 バックアップを開始する前にサービスを一時停止または休止することで、アプリケーション一貫性バックアップを実現できます。これには、すべてのI/O操作の停止、すべてのメモリー・バッファの同期、および処理中のトランザクションのフラッシュが含まれます。その後、APIコールを送信して、ボリュームまたはボリューム・グループをバックアップできます。
• バックアップを作成する前に、データの一貫性があることを確認します: ファイル・システムを同期して、可能な場合はファイル・システムをアンマウントして、アプリケーション・データを保存します。ディスク上のデータのみがバックアップされる。バックアップの作成中、バックアップ状態がREQUEST_RECEIVEDからCREATINGに変わったら、ボリュームへのデータの書込みに戻ることができます。バックアップの進行中は、バックアップされているボリュームを削除できません。
• 元のボリュームがアタッチされているリストアされたボリュームをアタッチするには、最初にパーティションIDを変更する必要がある場合があります。この要件は、同一のボリュームをリストアできないオペレーティング・システムによるものです。パーティションIDの変更手順については、オペレーティング システムのドキュメントを参照してください。

詳細は、ボリュームの手動バックアップおよび新しいボリュームへのバックアップのリストアを参照してください。

バックアップの主な用途は、ビジネスの継続性、ディザスタ・リカバリおよび長期的なアーカイブの要件をサポートすることです。バックアップ・スケジュールを決定する場合は、バックアップ計画および目標の次の側面を考慮してください。

• 頻度: データをバックアップする頻度。
• リカバリ時間: バックアップがリストアされて、それを使用するアプリケーションからアクセスできるようになるまでに待機できる時間。バックアップが完了するまでの時間はいくつかの要因に応じて異なりますが、バックアップ対象のデータのサイズと、前回のバックアップ以降に変更されたデータの量に応じて、通常は数分またはそれ以上になります。
• 格納されるバックアップの数: 使用可能な状態にしておく必要があるバックアップの数と、不要になったバックアップの削除スケジュール。一度に作成できるバックアップは1つしか作成できないため、バックアップの進行中は、それが完了しないと別ののバックアップを作成できません。格納できるバックアップの数の詳細は、ブロック・ボリュームの機能および制限を参照してください。

バックアップ使用の一般的なユース・ケース:

• 同じボリュームの複数のコピーを作成する必要がある場合。データ構成が同じ多数のボリュームを使用してインスタンスを作成する必要がある場合、バックアップが非常に有用です。

• 後で新しいボリュームにリストアできるように作業のスナップショットを取得する場合。
• プライマリ・コピーになんらかの問題が発生した場合に備えて、常にボリュームのスペア・コピーを用意しておく場合。

Oracle Cloud Infrastructure Block Volumeは、未使用の領域を再利用するために、ブート・ボリュームとブロック・ボリュームの両方に対してSCSI UNMAPコマンドをサポートしています。これらのコマンドを使用してバックアップ・サイズを減らし、バックアップのリストア時間を短縮します。詳細は、Support for SCSI UNMAPを参照してください。

ブロック・ボリュームをクローニングするための背景情報およびステップについては、ブロック・ボリュームのクローニングを参照してください。