差分バックアップで効率的なデータ保護：仕組み・増分との違い・注意点

差分バックアップで効率的なデータ保護：仕組み・増分との違い・注意点

差分バックアップとは、直近の完全バックアップを基準に、それ以降に追加・変更されたデータを保存する方式です。「毎日のバックアップを短時間で済ませたい」「保存容量を節約しながら、復元の手順も複雑にしたくない」という場合に検討できます。

理解の鍵は、変更をいつから数えるのかという点です。この記事では、完全バックアップを土台に変更分を重ねる仕組みから、増分バックアップとの違い、取得間隔や保管容量の決め方まで説明します。

差分バックアップ方式とは

バックアップは、機器の故障や誤操作などでデータを失ったときに備え、復元に使う控えを残すことです。差分バックアップはその保存方式の一つであり、AIに固有の技術ではありません。個人のパソコン、企業のファイルサーバー、仮想マシンなど、さまざまなデータ保護で使われます。

差分バックアップの出発点となるのが、保存対象のデータを一通り取得する「完全バックアップ」です。「フルバックアップ」「全体バックアップ」と呼ばれることもありますが、この記事では完全バックアップに統一します。ここでいう「完全」は指定した対象全体を指し、共有フォルダーだけを対象にした場合、パソコンのOSやほかのフォルダーまで自動的に保存されるわけではありません。

完全バックアップを取得した後は、そこから追加・変更されたデータを差分として保存します。一度差分に含めたデータも、次の完全バックアップを取得するまでは、その後の差分に引き続き含まれます。差分を取得しても、比較の基準は前回の差分へ移りません。この点が、直前のバックアップからの変更を保存する増分方式との大きな違いです。

なお、「変更された部分だけを保存する」といっても、文章を書き換えた数文字だけが保存されるとは限りません。ファイル単位の製品では、一部を編集したファイル全体が対象になります。ブロック単位の製品では、データを区切った一定の領域のうち、変更された領域を取得します。実際の保存量は変更した文字数ではなく、製品が採用する保存単位や処理方法によって変わります。

日別の具体例で見る保存と復元

日曜日に共有フォルダーの完全バックアップを取得し、月曜日にファイルAを更新、火曜日に別のファイルBを追加した例を考えます。わかりやすくするため、ここではファイル単位で保存し、ほかの変更や削除はないものとします。

火曜日に新しく操作したのはファイルBだけでも、火曜日の差分にはファイルAも入ります。日曜日の完全バックアップと比較すると、AもBも追加・変更された対象だからです。月曜日に保存済みであることを理由に、Aが火曜日の差分から外れるわけではありません。

火曜日にもファイルAを再編集した場合は、火曜日の差分にその取得時点のAを保存します。差分バックアップは、編集操作を一つずつ記録する仕組みではありません。たとえば朝と昼に書き換えて夜にバックアップした場合、その夜の状態は残せても、朝の編集直後の状態まで必ず戻せるわけではありません。

火曜日のバックアップ取得時点へ戻す場合、基本的な復元の流れは次のとおりです。製品によっては、復元時点を指定するだけで必要なデータの選択や適用を自動的に行います。

1. 火曜日の差分と、その基準である日曜日の完全バックアップを用意する。
2. 日曜日の完全バックアップから対象全体を復元する。
3. 火曜日の差分を反映し、ファイルAとBを火曜日の取得時点の状態にする。

火曜日へ戻すために、月曜日の差分を順番に適用する必要はありません。ただし、月曜日の状態にも戻せるようにするなら、月曜日の差分を残しておく必要があります。最新の差分だけを保管する運用では、過去の各取得時点を自由に選べるとは限らないためです。

また、火曜日の夜に取得した後、水曜日の朝に障害が起きれば、その間の変更はこのバックアップに含まれません。「最新の差分で復元できる」とは、障害直前ではなく、最後に正常に取得した時点へ戻せるという意味です。復元時の取り違えを防ぐため、各差分がどの完全バックアップに対応するかも管理しておきます。

完全・差分・増分バックアップの違い

三つの方式を比べるときは、「何を保存するか」と「復元時に何が必要か」を分けて見ると理解しやすくなります。以下は、圧縮や重複排除などの効果をいったん除いた、基本的な方式の比較です。取得量と時間は、変更量が全体より小さい場合の傾向を示しています。

先ほどの日別の例に当てはめると、完全方式は月曜日も火曜日も対象全体を保存します。差分方式は月曜日にA、火曜日にAとBを保存します。一方、基本的な増分方式では月曜日にA、火曜日にBを保存します。火曜日にAを再編集していなければ、増分にはAをもう一度含める必要がありません。

増分方式で火曜日へ復元するときは、日曜日の完全バックアップに、月曜日の増分、火曜日の増分を順に反映します。途中の増分が欠けると、その先の状態を正しく復元できない場合があります。差分方式は、途中の差分を使わずに復元できるため、必要な組み合わせを把握しやすいことが利点です。

ただし、必要なバックアップの組み合わせが少ないことと、復元時間が必ず短いことは別です。完全方式なら、戻したい時点の完全版だけで復元できます。差分方式では完全版を戻したうえで変更を反映するため、完全方式より速いと一律にはいえません。増分との比較でも、復元データ量、保存先の読み出し速度、ネットワーク、製品の処理によって所要時間は変わります。

また、増分データを製品側で統合するなど、運用者が意識する手順を減らす仕組みもあります。比較表は基本原理を理解するためのものであり、導入時には製品の復元方法と実際の所要時間を確認することが大切です。

差分バックアップの利点と向いている用途

差分バックアップは、データ全体に対して日々の変更量が小さく、取得負荷と復元手順の両方を抑えたい場合に向いています。毎回完全バックアップを取得する運用と比べ、保存容量だけでなく、保存先へ送るデータ量や取得にかかる時間も減らせる可能性があります。

たとえば、営業日報を蓄積するファイルサーバーには、過去の報告書や共有資料が大量に残っていても、当日追加する日報や修正する資料は一部だけという状況があります。このような場合、週末に全体を保存し、平日はそこからの追加・変更を差分として取得すれば、毎晩すべての過去資料をコピーする負担を抑えられます。誤って共有資料を上書きしたときも、必要な取得時点のバックアップを選んで復元できます。

保存量や転送量が減れば、保管費用や回線への負荷を抑えることにもつながります。また、夜間にバックアップを終えられれば、翌日の業務と処理が重なる事態を避けやすくなります。ただし、変更を調べるために多くのファイルを確認する製品もあり、保存量が半分になれば処理時間も半分になる、という関係ではありません。容量の効果と時間の効果は分けて確かめます。

適性は、更新の回数だけでは判断できません。何度も更新していても対象が少数の小さなファイルなら、差分は小さく収まる可能性があります。逆に、更新が一日一回でも、大きなファイルを広範囲に書き換えれば差分が大きくなります。変更が少ない環境でも容量節約の利点はありますが、対象全体が小さく、完全バックアップでも十分短時間で終わるなら、管理の単純さを優先する選択もできます。

仮想マシンも、利用するバックアップ製品が差分方式に対応していれば対象になります。仮想マシンは、一台の物理サーバー上などに作る仮想的なコンピューターです。そのディスク全体ではなく変更された領域を取得できれば、保存や転送の負担を減らせます。ただし、ファイルサーバーと同じく、実際にどれだけの領域が変化するかによって効果は異なります。

仮想マシンのバックアップでは、ある時点の状態を捉えるために「スナップショット」が使われることがあります。しかし、スナップショットは元のディスクや同じ保存装置に依存する場合があり、それだけで独立したバックアップになるとは限りません。状態を捉える機能と、故障時にも使える控えを別の保管先へ残すことを区別して運用します。

取得間隔と保管容量の決め方

取得スケジュールの例として、日曜日に完全バックアップ、月曜日から金曜日に差分バックアップを取得する構成があります。平日の差分は、いずれも日曜日の完全版を基準にします。翌日曜日に新しい完全バックアップを取得すると、その後の差分は新しい完全版を基準にする周期へ切り替わります。

完全版から時間がたつにつれ、変更された対象が増えると差分も大きくなりやすくなります。さらに、変更済みのデータは複数日の差分に繰り返し保存されるため、保管容量を見積もる際は最新の差分だけを見てはいけません。残しておく各世代の容量を合計する必要があります。

単純な例として、完全バックアップが100GB、月曜日の変更対象が2GB、火曜日に別の領域で変更された対象が3GBだったとします。変更対象は重複せず、各領域の大きさは変わらないものとし、圧縮、重複排除、管理情報などの影響は除きます。

火曜日の差分は、その日に変更した3GBだけではなく、月曜日の2GBを含む5GBです。日曜日の完全版と月曜・火曜の両世代を保管する場合、必要な容量は合計107GBになります。同じ2GBが月曜日と火曜日の両方の差分に含まれる点が、保管量を考えるうえでのポイントです。

一方、差分が毎日一定量ずつ増えるとは限りません。同じ領域を繰り返し更新する場合と、毎日別の領域を更新する場合では増え方が異なります。削除の扱いや圧縮率などによっても保存量は変わるため、数日から一周期分の実測をもとに見積もります。差分が大きくなりすぎるなら完全版を取得する周期を短くする方法がありますが、完全版そのものの取得時間と保管容量も必要です。

取得間隔は、どこまでのデータ損失を許容できるかを表すRPO（目標復旧時点）から検討します。たとえば毎日午前0時に正常に取得するだけなら、その次の取得直前に障害が起きた場合、約一日分の変更を失う可能性があります。一時間分までしか失えない業務なら、それに見合う取得間隔や、必要に応じた別の保護方法を検討します。取得失敗が続けば復元できる時点はさらに古くなるため、スケジュール設定と成功確認の両方が必要です。

これに対して、RTO（目標復旧時間）は、停止してから業務を再開するまでの目標時間です。「二時間以内に再開したい」なら、バックアップを読み出す時間だけでなく、復元先の準備、データの反映、アプリケーションの起動や動作確認まで含めて間に合うかを試します。RPOは主に取得間隔、RTOは主に復元手段や復元環境を考えるための目安になります。

最後に、戻せる時点をいくつ残すかという「保存世代数」を決めます。新しい完全版を作っても、前の週へ戻す必要があれば、前の週の完全版と差分を残します。新旧の完全版が同時に存在する期間や、取得失敗時に備える余裕も含めて、保管容量を確保しましょう。

復元に備える保管と運用の注意点

差分バックアップは基準となる完全版に依存します。完全バックアップが破損・消失すると、対応する差分だけでは対象全体を復元できません。差分に含まれないデータは完全版にしか残っていないためです。必要な差分を残したまま、その基準の完全版だけを古いという理由で削除しないようにします。

保管期限は、ファイルの日付だけで個別に判断するよりも、完全版とそれに対応する差分を一つのまとまりとして管理すると扱いやすくなります。製品に世代管理機能がある場合も、削除条件や依存関係の扱いを確認してください。古いバックアップを整理する前に、残す復元時点に必要な一式がそろっていることを確かめます。

保管先の分離も重要です。元データとバックアップを同じ機器の同じディスクに置くだけでは、ディスク故障で両方を失うおそれがあります。別媒体や別の保存装置へ控えを残し、災害への備えが必要なら別拠点も検討します。誤操作やランサムウェアなどによる同時被害に備えるには、オフラインで保管する控えや、書き換えを制限できる保存先も選択肢になります。

バックアップ処理の成功記録は必要ですが、それだけで復元できると判断せず、定期的に復元を試します。本番データを上書きしない検証先を用意し、必要なファイルが開けるか、内容や日時が期待どおりか、権限を含めて利用できるかを確認します。業務システムなら、データを戻した後にアプリケーションが正常に動くことまで確かめると、復旧時間の見積もりにも役立ちます。

復元の条件は、バックアップの対象によっても異なります。特に次の点は、取得前に利用製品の仕様や設定を確認しておきましょう。

• 稼働中のデータの整合性：データベースなどを更新中に単純コピーすると、関連データの時点がそろわない場合があります。アプリケーションに対応した取得機能や、必要な停止・連携手順を確認します。
• 削除情報の扱い：完全版の取得後に削除したファイルが、復元時にも削除された状態になるかは、記録方式や復元方法によります。「不要なファイルを戻さない」条件も含めて確認します。
• 暗号鍵や認証情報：暗号化したバックアップを戻すための鍵、パスワード、保存先へのアクセス手段を確保します。元の機器を失っても取り出せる管理が必要です。
• 復元に必要な環境：バックアップを管理するカタログ、対応ソフトウェア、復元先の容量など、データ以外に必要なものも把握し、手順に残します。

差分バックアップを選ぶ際は、実際の変更量、取得に使える時間、保存容量、RPOとRTOを照らし合わせます。まず一周期分の取得と復元を試し、差分の増え方や復旧の所要時間を確かめると、完全版を取り直す周期と必要な世代数を決めやすくなります。完全・差分・増分を理由なく混在させるのではなく、製品が対応する構成の中で、運用担当者が確実に復元できる方式を選びましょう。

差分方式の強みは、全体を毎回保存する負担を抑えながら、復元に必要なデータを「基準の完全版と対象時点の差分」にまとめられることです。その利点を生かすには、取得するだけで終わらせず、対応するデータの保持、保管先の分離、復元確認まで一続きの運用として整えることが大切です。

更新履歴