アプライアンスでは、上記のすべてのバックアップタイプを対象にレベルベースの増分バックアップをサポートしています。レベルバックアップを指定するには、通常 DMA で次の 3 つの環境変数を指定します。
|
定義によると、レベル N のバックアップには、N よりも小さい LEVEL を使用した同じシェアの同じバックアップセット (「DMP_NAME」で指定) の前回のバックアップ以降に変更されたすべてのファイルが含まれます。レベル 0 のバックアップには常にすべてのファイルが含まれます。UPDATE の値が「y」(デフォルト) の場合は、現在のバックアップが記録され、N よりも大きいレベルの将来のバックアップではこのバックアップがベースとして使用されます。これらの変数は通常 DMA によって管理されるため、管理者が直接構成する必要はありません。
増分バックアップスケジュールの例を次に示します。
|
その月の 24 日になったときにファイルシステムの状態を回復するには、通常、管理者はその月の 1 日に作成したレベル 0 のバックアップを新しいシェアに復元し、次にその月の 21 日に作成したレベル 1 のバックアップを復元し、最後にその月の 24 日に作成したレベル 2 のバックアップを復元します。
レベルベースの増分バックアップを実装するには、アプライアンスでシェアごとにレベルバックアップ履歴を追跡する必要があります。「tar」と「dump」のバックアップでは、レベルバックアップ履歴はシェアメタデータに保持されます。増分バックアップではファイルシステムがトラバースされ、前回のレベルバックアップ以降に変更されたファイルがバックアップに含まれます。復元時には、システムはバックアップストリーム内のすべてのファイルを復元するだけです。したがって、上記の例では 24 日のレベル 2 のバックアップを任意のファイルシステムに復元することが可能で、そのバックアップストリームに含まれるファイルは、復元先のファイルシステムがそのファイルのバックアップ元のファイルシステムと一致しなくても復元されます。ただし、元のファイルシステムの状態を回復するためには、空のツリーから始めて以前のレベルバックアップを復元する上記のような手順を使用することを最良事例としてお勧めします。
「zfs」タイプの効率的なレベルベースの増分バックアップを実施するには、別の方法が使用されます。増分セットに含まれているバックアップでは、バックアップに使用されたスナップショットを破棄するのではなくシステムに残します。その後の増分バックアップでは、このスナップショットをベースとして使用し、変更されたファイルシステムブロックをすばやく特定して、バックアップストリームを生成します。結果として、その後の増分バックアップを作成する場合は、バックアップ後に NDMP サービスによって残されたスナップショットを破棄してはいけません。
この動作のもう 1 つの重要な結論は、増分ストリームを復元するためには、ファイルシステムの状態が、増分ストリームのベーススナップショットでの状態とぴったり一致する必要があることです。つまり、レベル 2 のバックアップを復元するためには、ファイルシステムが前回のレベル 1 のバックアップが完了したときとまったく同じようになっている必要があります。上記の一般的な手順では、24 日のレベル 2 のバックアップストリームの復元時にシステムの状態は 21 日のレベル 1 のバックアップが完了したときとまったく同じであるため (そのバックアップが復元されたばかりなので)、このことが保証されます。
NDMP サービスでは、「zfs」の増分バックアップストリームを、最新のスナップショットが増分ストリームのベーススナップショットと一致しないファイルシステムに復元しようとした場合、またはファイルシステムがそのスナップショット以降に変更されている場合にエラーを報告します。復元が開始される直前にベーススナップショットにロールバックするよう NDMP サービスを構成できます。そのためには、NDMP 環境変数「ZFS_FORCE」に値「y」を指定するか、NDMP サービスの「データセットをロールバック」プロパティーを構成します (NDMP のプロパティーとログを参照)。