「フォーエバー・インクリメンタル・バックアップ」の解説
最近の研究によると、 企業の67％以上 マシンとデータを毎日、毎週、毎月、毎年バックアップします。マシンをバックアップする最も簡単な方法は、フルバックアップを作成することです。つまり、バックアップの実行ごとにマシン全体をバックアップリポジトリにコピーします。 ただし、フルバックアップの実行には時間がかかるという課題があります。特にマシンに大量のデータが保存されている場合、本番ネットワークに負荷がかかり、時間の経過とともにかなりのストレージ容量を占有することになります。
これらの問題に対処するため、今日のバックアップソリューションでは、本番ネットワークやストレージ容量に負担をかけずに最適な保護を実現できる増分バックアップなどの手法が提供されています。増分バックアップにはいくつかの種類があり、本記事では"増分バックアップ"と"フォーエバー増分バックアップ"の違いについて解説します。
増分バックアップ
増分バックアップとは、前回のバックアップ実行以降に作成または変更されたデータのみをリポジトリにコピーするバックアップ手法です。これにより、必要なデータ量のみが転送され、データの損失を完全に防ぐことができます。最初にフルバックアップを作成し、その後、一連の増分バックアップが行われます。
この増分バックアップのアプローチでは、両方の方法の利点、すなわちバックアップウィンドウの短縮、ストレージの節約、および復旧速度の向上を最大限に活用するために、定期的にフルバックアップを作成することを推奨します。したがって、復旧時には、バックアップソリューションは、最初のバックアップからすべての増分データを"再生"するのではなく、最新のフルバックアップファイルと、その後に作成された増分データに依存します。
バックアップソフトウェアでは通常、アクティブフルまたは 合成フルバックアップ方式:
- アクティブ・フル: バックアップはソースマシンを使用して作成されます。
- 合成素材(フル): バックアップは、本番環境のリソースを使用することなく、(バックアップリポジトリ内の)前回のフルバックアップとそれ以降のすべての増分バックアップを使用して作成されます。
以下は、増分バックアップの仕組みを示す例です。
増分バックアップの仕組み
この例では、VM内に3つのファイルがあり、各ファイルは1から4までの番号が付けられた4つのデータブロックで構成されています。最初のフルバックアップが実行されます 日曜日.
月曜日、 ファイル1のブロック1をブロック5に変更します。
増分バックアップ技術を使用する場合、バックアップアプリケーションはファイル1の3つのファイルや4つのブロックをコピーすることはありません。ファイル1の変更された1つのブロックのみをコピーし、このブロックがブロック1と置き換える必要があるという情報を送信するだけです。
火曜日、ファイル2にブロック6と7を追加します。ここでも、変更された部分のみがバックアップリポジトリにコピーされます。
水曜日, ファイル3を削除します。ファイル3が削除されたという情報以外は、データは転送されません。
増分バックアップは、ワークロードが多く、データ量も膨大な大規模な環境において特に効率的です。 環境内のすべてのVMに対して定期的にフルバックアップを実行すると、ストレージメディアに法外な予算が必要になってしまいます。例えば、Windows Server 2016(クリーンインストールに32GB必要)を搭載したVMが10台あり、それらすべてを毎日バックアップする必要がある場合、毎日320GB、週に2TB以上の空き容量を使用することになります。 簡単に言えば、毎週数台の新しいHDDが必要になる計算です。
この場合、最初にフルバックアップを作成する必要があります。つまり、合計320GBのスペースが必要です。各マシンの1日あたりの変更量が平均1GBだと仮定すると、1日あたり合計10GB、週あたり70GBのデータ量になります。これにより、同じ数のリカバリポイントでも、必要な容量は2TBをはるかに下回るものになります。
変更追跡技術
VM上の変更は、具体的にどのように追跡されるのでしょうか？VMware vSphere、Microsoft Hyper-V、Nutanix AHVの各ハイパーバイザーには、それぞれ独自の技術が採用されています。これらは 変更ブロック追跡(CBT) VMwareの"Resilient Change Tracking(RCT)"、Hyper-Vの"Changed Regions Tracking(CRT)"、Nutanix AHVの"Changed Regions Tracking(CRT)"などです。これらのネイティブ技術は、ソースデータの変更を特定する最も迅速な手段を提供し、バックアップウィンドウの短縮に貢献します。
また、何らかの理由でCBT、RCT、またはCRTを使用できない場合、多くのバックアップソリューションでは独自の変更追跡アルゴリズムを提供しています。 ネイティブの追跡技術は変更をリアルタイムで記録することを念頭に置いてください。対照的に、独自の追跡ツールは通常、変更を特定するためにVMの内容全体を読み取るため、このプロセスにはより多くの時間がかかる場合があります。
永続的な増分バックアップ
"フォーエバー・インクリメンタル・バックアップ"とは、最初のフルバックアップ以降、すべてのバックアップがインクリメンタルバックアップのみで行われるプロセスです。定期的なフルバックアップを前提とする従来のインクリメンタルバックアップとは異なり、フォーエバー・インクリメンタルを採用すると、すべてのバックアップが常にインクリメンタルバックアップとなります。
変更されたデータのみがコピーされるため、バックアップ処理は迅速に行われ、リポジトリに占有されるスペースも最小限に抑えられます。しかし、フォーエバー・インクリメンタル・バックアップの欠点は、復旧時に元のマシンを再構築するために時間がかかることです。 その理由は、リカバリ時にバックアップソリューションが、まず初期バックアップを復元し、その後、リカバリ日までのすべての増分バックアップを"リプレイ"して、システム全体を再構築する必要があるためです。
永続的増分バックアップの仕組み
前述の例に戻ると、バックアップアプリケーションはまず3つのファイルとそのすべてのデータブロックを復元し、次にファイル1のブロック1をブロック5に置き換え、ファイル2にブロック6と7を追加し、最後にファイル3を削除する必要があります。
一部のバックアップソリューションでは、依然としてこのアプローチが採用されています。一方、特定の"手法"を用いることで復旧速度を向上させることができるソリューションもあります。 例えば、NAKIVOのソリューションでは、リカバリポイントが増分への参照として機能する特殊なストレージタイプを提供しています。これにより、特定の時点でのVMを再構築するために必要なデータブロックを迅速に特定でき、リカバリ速度が向上します。
NAKIVO での増分バックアップの使用
NAKIVOのソリューションにおけるデフォルトのバックアップ方式は、"増分バックアップ＋フルバックアップ"のアプローチです。このモードを使用する場合、ソリューションは初期のフルバックアップ後に変更されたデータブロックのみを保存し、必要に応じて定期的にアクティブなフルバックアップまたはシンセティックバックアップを作成します。このアプローチにより、信頼性、速度、およびリソースの節約を両立させることができます。
結論
最新のデータ保護ソリューションでは、増分バックアップおよび永続的な増分バックアップを実行できます。これらのバックアップ方式には、次のようなメリットがあります:
- 増分バックアップでは、前回のバックアップ以降に行われた変更のみを追跡し、コピーします。
- VMwareはCBT技術を用いて変更を特定し、Hyper-VはHyper-V Server 2016以降RCTを採用しており、Nutanix AHVはCRTを採用しています。
- 独自の変更追跡アルゴリズムも利用可能ですが、処理速度は遅くなります。
- フォエバー・インクリメンタル・バックアップでは、最初のフルバックアップのみが必要で、その後は変更部分のみがコピーされます。
- 常に増分バックアップのみを行う方法の欠点は、復旧時にすべての変更内容を"再適用"する必要があるため、多大な時間がかかる可能性があることです。定期的な完全バックアップを作成することで、この問題を回避することができます。
時間と収納スペースを節約 NAKIVO Backup & Replication アプリケーションを意識した増分バックアップと、即時の詳細な復元を実現することで。
