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

ボリューム・バックアップを開始するには、管理者が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'

ブロック・ボリューム・サービスでは、2つのバックアップ・タイプを使用できます:

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

ボリューム・バックアップ・サイズは、現在のボリューム使用量より大きくすることができます。これには、次のような理由があります。

• 書き込まれたボリュームの一部は初期化済とみなされ、常にボリューム・バックアップに含まれます。

• 多くのオペレーティング・システムでは、これらのブロックが使用済とマークされるコンテンツを書込みまたはゼロにします。ブロック・ボリューム・サービスは、更新されたブロックを考慮し、これらのブロックをボリューム・バックアップに含めます。

• ボリューム・バックアップには、追加データ内の最大1GBのメタデータも含まれます。たとえば、256 GB Windowsブートディスクの完全バックアップでは、追加の1 GBのメタデータを含む257 GBのバックアップサイズが表示されることがあります。

コンソール、コマンドライン・インタフェース(CLI)、SDKまたはREST APIを使用して、ブロック・ボリューム・バックアップをリージョン間でコピーできます。ステップについては、リージョン間でのボリューム・バックアップのコピーを参照してください。この機能により、次のシナリオが拡張されます:

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

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

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

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

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を参照してください。

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

CLI、REST APIまたはSDKを使用して、ボリューム・バックアップとそのライフサイクルの自動化、スクリプト作成および管理を行うことができます。