2つのバックアップ間の変更済ブロック・トラッキングの直接API

Block VolumeダイレクトAPIにより、2つのバックアップ間で変更されたブロック・トラッキングが可能になります。

バックアップ/リストア・ソリューションのデータ保護サービス・ベンダーと開発者は、このインタフェースを使用して、2つのバックアップ間で変更されたブロックを識別し、バックアップ間のデルタ・データを直接取得して、バックアップ・ワークフローを分析および最適化できます。変更されたブロック・トラッキングを活用することで、2つのバックアップから2つのフル・ボリュームをリストアして比較および処理する必要がなくなり、より効率的なバックアップ・プロセスが可能になります。

このプロセスは、バックアップをリストアして新しいボリュームを作成するのと似ていますが、この場合、新しく作成されたボリュームには、2つのバックアップ間の差異のみが含まれます。

制限と注意事項の完全なリストは、制限事項と考慮事項を参照してください。

重要

変更されたブロックの使用が完了したらすぐに、変更されたブロックを含むボリュームを削除することをお薦めします。これらのボリュームは、変更されたブロックの取得以外の目的では使用しないでください。これらのボリュームはファイルシステムとして使用できません。

制限事項および考慮事項

この機能は、ブロック・ボリュームのバックアップおよびブート・ボリュームのバックアップでサポートされます。
ボリューム・グループ・バックアップの場合、個々のボリューム・バックアップの変更済ブロックをボリューム・グループ・バックアップから取得できます。
変更されたブロックの処理が完了したら、変更したブロックを含むボリュームを削除することをお薦めします。
リストアされたボリュームを通常のボリュームと同じ方法で使用することはできません。たとえば、使用可能なファイル・システムがない、ファイル・システムを作成してマウントすることはできません。
両方のバックアップが同じボリュームである必要があります。
最初のバックアップは、全体バックアップまたは増分バックアップです。2番目のバックアップは、増分バックアップである必要があります。両方のバックアップが増分バックアップの場合、2つの増分バックアップの間に完全バックアップが作成されていない必要があります。
バックアップ間でボリュームのサイズを変更しないでください。
推奨されるスキャン長は、最大1 GB相当の論理ブロックです。1 GBを超えるスキャン長はサポートされていません。出力は未定義です。スキャン長が0として指定されているか、まったく指定されていない場合、スキャン長はボリューム全体とみなされ、同じ制限の1 GBに従います。
変更されたブロックを取得するために作成されたボリュームは、「低コスト」パフォーマンス・レベルをサポートしていません。
コストに関しては、変更されたブロックを取得するために作成されたボリュームは、バックアップの元のソース・ボリュームと同じサイズになるため、そのように課金されます。
デフォルトでは、ブロック・ボリュームのブロック・サイズは4KBです。ブロック・サイズが大きいバックアップ形式にボリュームをエクスポートする場合は、ボリュームをリストアするときにchangeBlockSizeInBytesパラメータを使用して、外部バックアップ形式により大きなブロック・サイズを指定できます。

変更されたブロック・トラッキングの使用

直接APIを使用して、2つのバックアップ間で変更されたブロックを取得するには、次のステップを実行します。

1番目と2番目のバックアップOCIDsをソースとして指定することで、変更されたブロックを含むボリュームを作成します。
iSCSIアタッチメントを使用して、ボリュームをLinuxベースのインスタンスにアタッチおよび接続します。準仮想化アタッチメントはサポートされていません。Windowsベースのインスタンスへの添付はサポートされていません。
SCSI GET LBA STATUSコマンドを使用して変更されたブロックのアタッチされたボリュームをスキャンし、SCSI GET LBA STATUSによってレポートされた変更済ブロックを取得します。
ボリュームの処理が終了したら、ボリュームを削除します。まず、ボリュームを切断してインスタンスからデタッチする必要があります。

ステップ1: 変更されたブロックを含むボリュームの作成

CLIまたはAPIを使用して、2つのバックアップ間で変更されたブロックを含むボリュームを作成できます。最初のバックアップにはOCIDsを、ボリュームのソースには2番目のバックアップを指定します。

コンソールの「ソースの詳細」セクションの「ボリューム・タイプ」フィールドを確認することで、2つのバックアップからこのように作成されたボリュームを識別できます。ブロック・ボリュームの詳細の取得を参照してください。これらのボリュームのこのフィールドに指定された値は volumeBackupDeltaです。

CLIの使用

ブロック・ボリュームの場合、create-volume-volume-source-from-volume-backup-delta-detailsコマンドと必要なパラメータを使用して、ブロック・ボリュームを作成します。

oci bv volume create-volume-volume-source-from-volume-backup-delta-details --availability-domain <AD> --source-details-first-backup-id  <first_backup_ID> --source-details-second-backup-id <second_backup_ID> --source-details-change-block-size-in-bytes <change_block_size> [OPTIONS]

ブート・ボリュームの場合、create-boot-volume-boot-volume-source-from-boot-volume-backup-delta-detailsコマンドおよび必要なパラメータを使用してブロック・ボリュームを作成します:

oci bv boot-volume create-boot-volume-boot-volume-source-from-boot-volume-backup-delta-details --availability-domain <AD> --source-details-first-backup-id  <first_backup_ID> --source-details-second-backup-id <second_backup_ID> --source-details-change-block-size-in-bytes <change_block_size> [OPTIONS]

CLIコマンドのフラグおよび変数オプションの完全なリストは、コマンドライン・リファレンスを参照してください。

APIの使用

CreateVolume API

CreateVolume操作を使用し、CreateVolumeDetailsにVolumeSourceFromVolumeBackupDeltaDetailsを指定します。

この操作のパラメータは、次のとおりです。

firstBackupId: 比較する最初のバックアップのOCID。このバックアップは、2番目のバックアップより古い必要があります。
secondBackupId: 最初のバックアップと比較するバックアップのOCID。このバックアップは、最初のバックアップより新しい必要があります。
changeBlockSizeInBytes: (オプション)デフォルトでは、ボリュームのブロック・サイズは4KBです。リストアされたボリュームをより大きなブロック・サイズのバックアップ形式にエクスポートする場合は、このパラメータを使用して、外部バックアップ形式の大きいブロック・サイズと一致する大きいブロック・サイズを指定します。4096年から1048576年まで、二つの力で。デフォルトは4096です。
type: volumeBackupDelta。

CreateBootVolume API

CreateBootVolume操作を使用し、CreateBootVolumeDetailsにBootVolumeSourceFromBootVolumeBackupDeltaDetailsを指定します。

この操作のパラメータは、次のとおりです。

firstBackupId: 比較する最初のバックアップのOCID。このバックアップは、2番目のバックアップより古い必要があります。
secondBackupId: 最初のバックアップと比較するバックアップのOCID。このバックアップは、最初のバックアップより新しい必要があります。
changeBlockSizeInBytes: (オプション)デフォルトでは、ボリュームのブロック・サイズは4KBです。リストアされたボリュームをより大きなブロック・サイズのバックアップ形式にエクスポートする場合は、このパラメータを使用して、外部バックアップ形式の大きいブロック・サイズと一致する大きいブロック・サイズを指定します。4096年から1048576年まで、二つの力で。デフォルトは4096です。
type: bootVolumeBackupDelta。

レスポンス・コード


レスポンス・コード	説明
`200 OK`	リクエストは正常に完了しました
`400 Bad Request`	返されるメッセージに応じて、このコードは次のシナリオで返されます。 `firstBackupId`または`secondBackupId`に指定されたOCIDが無効であるか、形式が正しくありません。 `firstBackupId`と`secondBackupId`の両方に同じOCIDが指定されます。 `firstBackupId`で指定されたバックアップは、`secondBackupId`で指定されたバックアップより後に取得されました。 `volumeBackupDelta`に指定された値が無効であるか、正しい形式ではありません。
`403 Forbidden`	このコードは、次の場合に戻されます。 `firstBackupId`および`secondBackupId`で指定されたバックアップは同じボリュームからのものではありません。ボリュームは、`firstBackupId`および`secondBackupId`で指定されたバックアップ間でサイズ変更されました。
`404 Not Found`	返されるメッセージに応じて、このコードは次のシナリオで返されます。バックアップ・リストア・デルタ機能がテナンシに対して有効になっていません。指定したバックアップは存在しません。「低コスト」パフォーマンス・レベルが指定されました。このレベルは、バックアップ・リストア・デルタ機能を使用してボリュームを作成する場合にはサポートされません。
`409 Conflict`	このコードは、いずれかのバックアップのライフサイクル状態が「使用可能」でない場合に返されます。
`500 Internal Server Error`	サーバーはリクエストの実行を妨げる予期しない条件が発生しました。

監査ログ

監査ログは、すべてのボリューム作成操作に対して生成されます。2つのバックアップ間で変更されたブロックを含むボリュームのソースとして使用される1番目と2番目のバックアップの詳細を確認できます。詳細は、次の例に示すように、ログ・データのsourceDetails要素にあります。

 "sourceDetails": {
            "changeBlockSizeInBytes": 1048576,
            "firstBackupId": "ocid1.volumebackup.oc1.eu-paris-1.<first_backup_unique_ID>",
            "secondBackupId": "ocid1.volumebackup.oc1.eu-paris-1.<second_backup_unique_ID>",
            "type": "volumeBackupDelta"
          },

これらのボリュームのtype属性はvolumeBackupDeltaです。

詳細は、監査の概要および監査ログ・イベントの表示を参照してください。

ステップ2: 変更されたブロックを含むボリュームのアタッチと接続

ボリュームの作成後、ボリュームのスキャンを開始する前に、iSCSIアタッチメントを使用してLinuxベースのインスタンスにアタッチする必要があります。Windowsベースのインスタンスへの疑似仮想化アタッチメントおよびアタッチメントはサポートされていません。

これらのタスクの詳細は、次のトピックを参照してください。

ステップ3: SCSI Get LBAステータスで変更されたブロックのボリュームのスキャン

ボリュームをLinuxベースのインスタンスにアタッチして接続した後、SCSI GET LBA STATUSコマンドを使用してアタッチされたボリュームで変更されたブロックをスキャンし、コマンドによってレポートされた変更済ブロックを取得できます。

SCSI GET LBA STATUSの使用

SCSI GET LBA STATUSコマンドをブート・ボリュームとブロック・ボリュームの両方に送信して、指定した開始論理ブロック・アドレス(LBA)のボリューム上の変更済ブロックと、変更されたブロックを識別するためにスキャンする長さ(スキャン長)を検出して取得できます。デバイス上のブロックのプロビジョニング・ステータスの返却にかかる時間は、コマンドで提供されるスキャン長、およびボリュームに構成されたパフォーマンス・レベルによって異なります。

sg3_utilsは、sg3_utils-1.48からビルドおよびインストールできます。「マニュアル」も参照してください。

LBAステータスの使用に関する制限事項と考慮事項

Linux用の32バイトコマンドは、サポートされている唯一のバージョンです。Linuxの16バイトコマンドはサポートされていません。
Windowsではコマンドはサポートされていません。
iSCSIでアタッチされたボリュームのみがサポートされています。
推奨されるスキャン長は、最大1 GB相当の論理ブロックです。スキャン長(-s)の使用方法については、次の項の例を参照してください。1 GBを超えるスキャン長はサポートされていません。出力は未定義です。スキャン長が0として指定されているか省略されている場合、動作は未定義です。
デフォルトの割当て長は24バイトで、記述子は1つのみです。
レポート・タイプが0 (すべて)の場合、未初期化ブロックのプロビジョニング・ステータスも結果に含まれます。これは、未初期化ブロックと明示的に割当て解除されたブロックの区別がないためです。

例

この項の詳細は、Linuxインスタンスでコマンドを実行して変更されたブロックを取得する例を示しています。

マップ済ブロックおよび割当て解除済ブロックに関するプロビジョニング・ステータスのみを取得し、初期化されていないブロックについては、レポート・タイプ1を使用してゼロ以外のプロビジョニング・ステータスを指定します。

例:

sudo sg_get_lba_status -b -T -l 96 -m 32768 -s 2097152 -t 1 /dev/sdc

前述の例では、論理ブロック・サイズは512バイトで、ブロック・デバイスは/dev/sdcです。この例では、32バイト・コマンド(-T)を使用し、割当て長が32768バイトのlba 96から開始して、1 GB (または2097152の連続する論理ブロック)をスキャンします。指定したレポート・タイプは1です。-bオプションを指定すると、出力が簡単に出力されます。

出力の理解

次に、前のコマンドの実行例の出力例を示します。

Completion condition=3
RTP=1
0x0000000000000060  0x10  3  0
0x0000000000000070  0x8  1  0
0x0000000000000078  0x10  3  0
0x0000000000000088  0x8  1  0
0x0000000000000090  0x10  3  0
0x00000000000000a0  0xfff60  1  0

前述の出力には、6つの記述子が含まれており、それぞれに、その多数の連続するブロックの開始lba、カウントおよびプロビジョニング・ステータスがあります。

たとえば、最初の記述子の開始lbaは96、カウントは16、プロビジョニングステータスは3、つまり96から112までのブロックがマップされます。

RTP=1は、コマンドで送信されたレポート・タイプがLbaステータスの取得コマンドの処理中に考慮されたことを意味します。

出力例の4つの完了条件タイプは次のとおりです。

完了条件= 0: デバイスサーバーが出力を返しませんでした。
完了条件= 1: 割り当て長が満たされたときにデバイスサーバーが処理を停止し、次のコマンドは出力の最後のlbaのあとに開始lbaを使用する必要があります。
完了条件= 2: デバイスサーバーがスキャン全体の長さをスキャンし、出力を返しました。したがって、次のコマンドは、前に送信されたスキャン長の後に開始lbaを使用できます。
完了条件= 3: デバイスサーバーがボリュームの最後に達したため、出力の最後のlbaのあとにコマンドを送信しないでください。

ステップ4: 変更されたブロックを含むボリュームの削除

2つのバックアップ間で変更されたブロックを含むボリュームは、変更されたブロックの取得以外の目的では使用しないでください。そのため、変更されたブロックの使用が完了したらすぐにこれらのボリュームを削除することをお薦めします。

まず、インスタンスからボリュームを切断してから、インスタンスからボリュームをデタッチする必要があります。ボリュームをデタッチした後、そのボリュームを削除できます。

Oracle Cloud Infrastructureドキュメント