1 差分バックアップの概要
1.1 定義と基本概念
差分バックアップとは、基準として定めたフルバックアップ（またはそれに準ずるバックアップ）以降に新たに作成された、あるいは更新されたデータのみを収集して保存する方式である。実際の差分採取では、「基準以降に変更が生じた範囲」を検出し、その範囲に該当するデータだけをバックアップ媒体へ書き込む。
復元では、最後に得られているフルバックアップを土台として読み出し、そこに差分バックアップを順に組み合わせることで、目的とする時点の状態に近い復元結果を作る。差分バックアップの価値は、フルの採取頻度を抑えつつ、復元に必要なデータ量を一定の範囲に収めやすい点にある。
1.2 フルバックアップとの差分バックアップ
1.2.1 変更検出の考え方
フルバックアップが対象全体を定期的に丸ごと複製するのに対し、差分バックアップでは基準以降の変更に着目する。検出の方法としては、更新日時や更新フラグ、追跡ジャーナル、差分ビットマップなどが用いられる。重要なのは、変更の識別が「基準からの経過」に基づく設計になっていること、そしてその識別情報が復元に利用できる形で保持されることである。
差分方式の特徴は、基準以降の変更が累積しやすい点にある。つまり、差分を取るたびに「直近分だけ」になるとは限らず、基準からの差分として増えていく振る舞いが起こり得る。
1.2.2 復元に必要なデータの組み合わせ
差分バックアップの復元に必要な材料は、基本的に「最新のフルバックアップ」および「目的時点に対応する差分バックアップ」である。運用設計によっては、複数回の差分を組み合わせて追い込む運用もあるが、一般的には基準フルに対して整合する差分を選択する形で復元が成立する。
復元時には、メタデータや整合性のための補助情報が矛盾なく揃っていることが前提になる。したがって、差分採取の失敗や媒体の欠落、保持期限による世代削除が起きると、復旧が難しくなる可能性がある。
1.3 用語の整理
差分バックアップでは、基準データと変更範囲の考え方が中心になるため、関連用語を整理しておくと運用が安定する。
基準バックアップとは、差分採取の基点となるフルバックアップ（または基準点として扱うバックアップ）のことである。差分ビットマップとは、変更の有無を示すための管理情報を指し、差分の範囲決定に使われることがある。世代管理とは、保持するバックアップの集合を決め、削除やローテーションを整合的に行う仕組みである。ポイントインタイムは、復元で狙う任意の時点を意味し、差分方式ではその時点に対応するバックアップ群を組み合わせる発想につながる。
2 仕組みと動作原理
2.1 変更の記録方法
2.1.1 更新日時・差分ビットマップ・ジャーナル等
差分方式の根幹は「基準以降の変更がどこで起きたか」を示す記録の存在にある。代表的には更新日時を参照する方式、差分ビットマップで変更単位のフラグを管理する方式、ファイル更新イベントをジャーナルとして追跡する方式などがある。
更新日時ベースでは、時刻の粒度やタイムスタンプ改変の影響を受ける場合がある。差分ビットマップでは、基準以降に変更された領域にフラグが立つことで、差分の採取範囲を素早く決められる。ジャーナル方式では、更新履歴が記録されるため、正確な差分範囲を再現しやすい一方、ジャーナルの保持や欠落が復元の成否に影響する。
2.1.2 ファイル単位とブロック単位
差分の粒度には、ファイル単位とブロック（またはセクタ）単位の考え方がある。ファイル単位では、更新されたファイルだけを対象にするため実装が分かりやすいが、大きなファイルの一部更新でも全体を扱う形になり得る。
ブロック単位では、変更された領域だけを記録・転送するため、データ量を抑えやすい。ただし、ストレージや整合性の管理が複雑化しやすく、復元時の整合処理も慎重な設計が求められる。
2.2 ストレージへの書き込み戦略
2.2.1 追記型と上書き型
バックアップ媒体への書き込みは、追記型と上書き型に大別される。追記型では、新しい差分データを既存領域に追加していくため、復元時に過去情報を辿りやすい利点がある。上書き型では、媒体利用効率を上げやすい一方、保持方針を誤ると必要な世代が失われやすい。
差分方式では、基準からの差分が累積し得るため、書き込み方針とローテーションの関係を明確にする必要がある。つまり「削除してよい範囲」がどのメタデータに依存しているかを把握することが重要になる。
2.2.2 メタデータ管理
差分バックアップの実体データに加えて、復元に必要なメタデータを適切に保存することが求められる。メタデータには、基準バックアップ識別子、作成時刻、変更範囲の管理情報、整合性チェック結果、参照関係などが含まれる。
メタデータが欠落したり壊れたりすると、データ本体が残っていても復元が成立しない場合がある。したがって、データとメタ情報の保護レベル、冗長性、整合性確認のタイミングを揃えることが運用上の要点になる。
2.3 復元プロセス
2.3.1 復元の基本手順
復元手順は、まず対象の基準フルを特定し、次に目的時点に対応する差分を選択して読み込む流れになる。選択では、世代管理のポリシーにより保持されているものだけが候補になるため、事前に「どの組み合わせで復元できるか」を設計と検証で確認しておくのが望ましい。
その後、復元ツールは整合性処理を行い、差分の変更情報をフルに適用して対象状態を組み立てる。最後に、ファイルの存在確認や簡易な整合性テスト、アプリケーション起動確認などを行って結果を評価する。
2.3.2 目標時点（ポイントインタイム）の扱い
差分方式でポイントインタイムを扱う場合、「どの時点の差分が保持され、基準との整合が保たれているか」が鍵になる。目的時点が差分の採取時刻に厳密に一致しない場合、復元可能な近傍の時点が制約になることがある。
また、更新中のデータやトランザクションの途中状態をどう扱うかも考慮対象である。ファイルシステムやデータベースの整合性を確保するため、凍結、スナップショット利用、ジャーナル適用などの補助策が必要になるケースがある。
3 運用設計の考え方
3.1 バックアップ計画
3.1.1 フルの頻度
フルバックアップの頻度は、差分の成長速度と復元時の負担に影響する。フルを間隔広めにすると、基準以降の変更が長く累積しやすくなり、差分データ量や採取時間が増える傾向がある。反対にフルを頻繁にすると差分は小さくなりやすいが、その分フル採取のコストが増える。
頻度は、変更量、データ保全の必要度、バックアップウィンドウ、運用体制を踏まえて決めるのが一般的である。設計の目的は「平均コスト」だけでなく、障害時に成立する復旧手順の現実性を高めることにある。
3.1.2 差分の取得頻度
差分の取得頻度が高いほど、目標時点に近い状態へ復元しやすくなる。ただし、差分データの採取と転送、メタデータ更新の負荷も増える。特に基準以降の累積が起きる方式では、採取回数を増やしても差分サイズが常に小さくなるとは限らない。
運用設計では、復旧目標（許容できるデータ損失の範囲）とバックアップの実行可能時間（同時処理や低負荷時間帯の確保）を両立させる視点が必要である。
3.2 世代管理（保持ポリシー）
3.2.1 世代数の決定
保持する世代数は、コストと復元可能性の妥協点になる。差分方式では、基準フルを削除すると、その基準に紐づく差分も復元に使えなくなる可能性が高い。したがって、単に差分の世代だけを数で決めるのではなく、「フルと差分の依存関係」を含めた計画が必要になる。
具体的には、復旧で必要な最長遡及期間を設定し、その期間をカバーできる基準フルの保持と、対応する差分の保持を組み合わせて定義するのが合理的である。
3.2.2 世代削除の整合性
世代削除では、削除対象の判定ロジックが整合しているかが重要になる。フルを削除したあとに差分だけが残る状態は、復元の組み合わせが成立しないリスクを生む。逆に差分を削ってしまうとポイントインタイムへの到達が難しくなる。
よい運用では、削除前に「成立する復元経路」を検査し、必要な参照関係が維持されるように制御する。自動削除機能を使う場合でも、設定内容を文書化し、変更時に再検証することが望ましい。
3.3 性能とコストの見積もり
3.3.1 保存容量の変動
差分バックアップは、フルより節約できることが多いが、差分が基準以降に累積する設計の場合、時間とともに保存量が増えやすい。結果として、運用開始直後は軽く見えても、しばらく経つと容量が膨らむ場合がある。
見積もりでは、過去の変更率、ファイル数、平均更新頻度、更新サイズの傾向を材料にして、差分の成長カーブを仮定するのが現実的である。さらに、メタデータや検証ログ、重複排除の有無なども含め、総合的な消費を捉える必要がある。
3.3.2 バックアップ時間の見通し
バックアップ時間は、データ読み出し、変更範囲の判定、転送、媒体への書き込みの合算として見積もられる。差分は対象範囲が絞れるため短くなることがあるが、変更が多い期間や基準からの経過が長い状態では処理時間が延びることもある。
時間の変動に備えるには、実行ログからボトルネック（読み出し待ち、ネットワーク輻輳、書き込み待ちなど）を特定し、閾値アラートや実行スケジュールの調整に反映する運用が有効である。
4 他方式との比較と選定
4.1 増分バックアップとの違い
4.1.1 復元手順の複雑さ
増分バックアップは直前のバックアップ以降の変更だけを保存するのが一般的である。差分と比べると、復元に必要なバックアップ連鎖の数が増えやすく、手順や検証作業が煩雑になる場合がある。
差分方式は、復元において基準フルと差分の組み合わせで成立しやすく、手順の整理がしやすい傾向がある。ただし、ポイントインタイムの厳密さや保持方針により、実務上の負担は変動する。
4.1.2 データ増加の傾向
差分は基準からの経過で変更範囲が広がりやすい一方、増分は直前間隔に限定されるため、個々の増分サイズが比較的小さく保たれることがある。そのため、採取側のコストは増分が有利に見える場合があり、復元側の負担は差分が軽く見える場合がある。
どちらが望ましいかは、変更率の性質（一定なのか、波があるのか）、復旧頻度の見込み、復旧要員のスキル、検証可能な手順の作りやすさなど、運用条件に左右される。
4.2 ミラーリング・スナップショットとの関係
4.2.1 目的別の使い分け
ミラーリングは主に可用性確保（即時復旧の容易さ）に重きを置くことが多く、差分バックアップはデータ保全や時間遡及の目的で活用されるケースが多い。スナップショットは短時間で状態を切り出す手法として有用であるが、バックアップとして長期保持や災害対策まで含めるかは設計次第である。
目的を切り分ける際は、「短時間の復元」「長期保管」「人為的ミスへの備え」「物理障害や災害への備え」などを整理し、それに応じた技術を組み合わせるのが実務的である。
4.2.2 復元要件との整合
復元要件には、許容される損失時間（復旧の起点）と、復元後に求める整合状態（アプリケーションが正しく動くか）が含まれる。差分バックアップは整合性検証と復元手順の設計によって、これらの要件を満たし得る。
ただし、スナップショットだけに依存すると、運用期間や保持設計によっては必要な時点を復元できないことがある。逆に、バックアップだけでも時間遡及が粗い設計では期待値を下回る可能性がある。要件に対してギャップがないかを、事前検証で詰めることが重要になる。
4.3 方式選定の指針
4.3.1 RPO/RTOの考慮
RPO（目標復旧時点）はデータ損失の許容範囲であり、差分の採取頻度と保持の範囲が関係する。RTO（目標復旧時間）は復旧にかかる時間の上限であり、復元手順の短さや検証のしやすさが影響する。
差分方式は、復元時に基準フルと差分の適用で済む見通しを立てやすいため、RTO面で有利に働くことがある。一方で、差分サイズの累積による復元・採取時間の伸長があるため、RPOとRTOを同時に満たす設計として具体化する必要がある。
4.3.2 可用性と運用負荷のバランス
差分バックアップの選定では、技術性能だけでなく運用負荷が重要になる。差分の世代関係が複雑にならないように保つこと、復元手順を定型化すること、テストを継続できる体制を作ることが、実効性を左右する。
また、障害時に復旧担当が確実に動けるよう、手順書、チェックリスト、ロールバック計画を揃えることが望ましい。結果として、可用性を維持しながらコストを抑える運用バランスが作りやすくなる。
5 導入時の要件と注意点
5.1 対象データの範囲
5.1.1 ファイルシステム
ファイルシステムを対象にする場合、パス単位の変更検出だけでなく、メタデータ更新や権限変更の扱いを確認する必要がある。差分方式では、更新されたと判断された範囲が復元時に反映されるため、どの属性が「変更」と見なされるかが重要になる。
さらに、ファイルロックや更新中ファイルへの対応も考慮対象である。整合性確保のために凍結手順や整合スナップショットの利用が必要になることがある。
5.1.2 データベースや仮想環境
データベースでは、ファイル単位ではなくトランザクション整合の観点が必要になる。差分バックアップが正しく機能するには、バックアップ対象の整合性レベルが確保されること、必要な補助情報が保存されることが前提になる。
仮想環境では、仮想マシンのスナップショットやジャーナリング機能と差分バックアップの役割を整理する必要がある。仮想化基盤側の状態切り出しと、バックアップソフト側の変更検出が矛盾しないよう、組み合わせを検証することが望ましい。
5.2 整合性（整合チェック）
5.2.1 オフライン/オンライン整合性
オフライン整合性は、バックアップ中に対象を停止または凍結して整合状態を保つ考え方である。オンライン整合性は、稼働状態を維持しながら整合性を確保するための仕組みを用いる。どちらが適するかは業務影響と、対象の特性による。
差分方式では整合性の失敗が差分の適用で増幅される恐れがある。したがって、対象に応じた整合性手段を採用し、バックアップ実行時の条件（負荷、ロック状態、タイミング）を安定させる必要がある。
5.2.2 確認手順の設計
整合性確認には複数段階があり得る。まずはバックアップ作成の成功判定（ジョブ終了コード、容量、書き込み完了）を行う。次に、復元テストや検証スキャンで内容の整合を確認する。
手順設計では、どの頻度で何を確認するかを定義し、失敗時にどの経路で原因調査へ進むかを決めておく。結果として、「作れたはず」という思い込みを減らし、復旧可能性を高める。
5.3 例外系と典型的な失敗
5.3.1 世代切れによる復元不能
差分方式では基準フルが復元の根拠になる。世代削除が原因で基準フルが失われる、あるいは差分が基準に対応していない状態になると、復旧が成立しない。これが「世代切れによる復元不能」の代表例である。
対策としては、削除ポリシーを依存関係に沿って設計し、削除前の検査や復元経路の可否チェックを自動化することが有効である。
5.3.2 変更検出の取りこぼし
変更検出の取りこぼしは、更新日時のズレ、タイムスタンプ補正、更新フラグの不整合、ジャーナル欠落などで起こり得る。差分の採取は「変更がある」と判断された範囲だけを含むため、取りこぼしがあると復元結果が目的から外れる。
対策として、対象ごとに適切な検出方式を選び、設定条件を固定し、定期的な復元テストで実際の差分反映を確認することが重要になる。結果の不一致が見つかった場合は、基準からのやり直し（基準フルの更新）を検討する。
6 セキュリティと保護
6.1 アクセス制御
6.1.1 認証・認可
バックアップは復旧に直結する資産であるため、アクセス制御の強度を通常運用よりも高めに設計することが望ましい。認証・認可では、少なくとも読み取りと管理操作を分離し、作業権限の最小化を徹底する。
加えて、バックアップ管理画面やAPIの権限、媒体への書き込み権限、鍵を扱う権限を同一主体にまとめない方が安全性が高まる。運用担当の異動も考慮し、棚卸しを定期的に行う。
6.1.2 監査ログ
監査ログは、誰がいつ何を操作したかを追えるようにするための仕組みである。差分バックアップでは、ジョブ実行、失敗、削除、復元要求などのイベントが監査対象になりやすい。
ログの設計では、保存期間、改ざん耐性、参照経路を含めて考える必要がある。災害や侵害が起きた後に、ログが見られない状態では原因究明の価値が下がる。
6.2 取り扱い上のリスク
6.2.1 ランサムウェア対策の考え方
ランサムウェア対策では、バックアップが攻撃者に暗号化される、あるいは削除されるといった「二次被害」を防ぐことが重要になる。差分方式では保持世代が依存関係を持つため、基準側を失うことが致命傷になり得る。
一般に有効な考え方として、分離された保管（オフラインや書き込み制限）、復元テストを含む耐性検証、権限分離による操作抑制などがある。具体策は環境に合わせて選び、定期的に妥当性を確認する。
6.2.2 暗号化と鍵管理
暗号化は機密性の確保に寄与するが、鍵管理を誤ると復元できないという新たな問題を生む。したがって、暗号化方式と鍵の保管場所、鍵のローテーション方針、復元時の復号手順を一体で設計する。
鍵の権限制御やアクセスログ、バックアップ側と復元側での鍵整合性確認も重要である。鍵が別システムに依存する場合は、障害時の復元シナリオまで含めた検証を行う。
6.3 保管場所の設計
6.3.1 オンプレとクラウド
保管場所は、コストや運用負荷だけでなく障害ドメインの分離に関係する。オンプレ保管はネットワーク制約や管理統制を維持しやすい一方、自然災害や電源喪失といった大きなリスクは同一施設内に残ることがある。クラウド保管は冗長性の恩恵を得やすいが、ネットワーク障害や料金設計の影響を受ける。
差分方式では保持世代が増えるため、転送経路や保存コストを見積もりに含めることが重要になる。
6.3.2 地理分散
地理分散は、同一地域の障害や災害に対する耐性を高める考え方である。復元手段として地理的に離れた保管を用意すると、重大な損失が起きても復旧できる確率が上がる。
設計では、同期頻度、復旧手順の違い、通信コスト、鍵管理やアクセス制御の統一を考慮する必要がある。特に復元が遅れる要因（帯域、復号、展開）を見積もり、RTOを満たすか確認する。
7 テスト・検証と運用改善
7.1 復元テストの重要性
7.1.1 定期テストの設計
バックアップは作った瞬間ではなく、復元できた時点で価値が確定する。差分方式では基準フルと差分の組み合わせが成立しているかが重要なため、復元テストは定期的に実施するのが望ましい。
テスト設計では、頻度、対象（主要サーバ、代表的なデータセット）、評価項目（ファイル整合、アプリ起動、基本クエリ成功など）を定義する。すべてを毎回行うのではなく、リスクに応じて段階化する。
7.1.2 手順書と記録
手順書は、復元の再現性を高めるための基盤である。差分方式では、どの基準フルを選び、どの差分を組み合わせるかを明確に記載する必要がある。
記録では、実施日時、対象、使用したバックアップ世代、結果、所要時間、問題点を残す。これにより、失敗の原因分析と次回改善が行いやすくなる。
7.2 モニタリングとアラート
7.2.1 成功/失敗の指標
モニタリングでは、ジョブの成否だけでなく、容量、転送速度、処理時間、メタデータ更新の成功などの指標を追うと運用が安定する。差分方式では差分サイズの増減が変化要因を示すため、その推移が閾値を超えた場合の検知も有効である。
アラート設計では、誤検知を減らしつつ、重要な異常を見逃さないバランスが必要になる。
7.2.2 失敗時の切り分け
失敗時には、原因が「採取側の不具合」「ネットワークや媒体の問題」「整合性チェックの失敗」「権限エラー」など複数候補に分かれる。切り分けでは、ログの参照順序、再実行の可否、基準フルの状態確認などを手順化するのが望ましい。
特に、基準フルに影響が出た可能性がある場合は、差分の採取を止めて整合性を優先確認する。復旧計画の整合が崩れる前に判断することが重要である。
7.3 運用改善のサイクル
7.3.1 ボトルネック分析
ボトルネック分析では、バックアップ処理のどの段階が遅れているかを特定する。差分方式では変更範囲の判定や読み出し量が増えた結果として時間が伸びることがあり、理由の切り分けが必要になる。
分析には、メトリクスの時系列、ジョブごとの比較、対象データの変更傾向の突合などを用いる。単なる「遅かった」の報告で終わらせず、次の施策につなげる。
7.3.2 設定見直しと再検証
改善策は、保持ポリシー、取得頻度、並列度、検出方式、暗号化設定など多岐にわたる。変更後は、期待通りの差分サイズになったか、復元手順が成立するか、整合性が維持されるかを再検証する。
特に世代管理やポイントインタイムの扱いは、設定ミスが復元不能へ直結し得るため、変更は段階的に行い、テスト結果を記録することが重要になる。
8 よくある質問（軽いトピックを含む）
8.1 「差分が大きくなり続ける」のはなぜ？
差分が基準以降の累積として扱われる設計の場合、基準から遠ざかるほど「変更されたと判定された領域」が増えやすい。結果として、直近だけでなく過去に更新された分が含まれているように見えることがある。
また、更新日時の扱い、メタデータだけの更新が変更扱いになっている、あるいはタイムスタンプの更新が過剰に発生していると、実データの変化量以上に差分が膨らむことがある。運用では検出粒度や判定ルールを確認し、必要なら基準フルの周期を見直す。
8.2 「復元が意外に手間」になりやすいケース
復元が手間になる典型は、保持世代の依存関係が崩れている場合である。基準フルが消えていた、差分が基準と対応していない、または復元に必要なメタ情報が欠落していると、作業が長引きやすい。
次に多いのは、整合性確認の段階で追加作業が発生するケースである。アプリの起動テストまで含めると想定より時間がかかることがあるため、復元手順の評価項目を事前に整理しておくと見通しが立つ。
8.3 運用あるある（バックアップ担当あるある）
バックアップ担当の「あるある」としては、差分ジョブが成功しているのに、復元テストでだけ小さな不整合が見つかることが挙げられる。原因が微妙なタイムスタンプ差やメタデータの扱いである場合、直すまでに試行錯誤が必要になりがちである。
また、世代削除が一度だけ失敗し、その後の数週間は“たぶん大丈夫”で回してしまう、というパターンもある。軽い気持ちで進めると事故の芽になるため、テストと検証を地道に続けるのが最終的に一番早い、というのが実務の結論になりやすい。