1 完全バックアップの概要
1.1 定義と目的
完全バックアップ（full backup）は、対象データを復元可能な形で丸ごと複製し、リストア時に同じ時点の全体状態を再現することを狙う方式である。増分や差分のように「前回以降の変更分だけ」を別途組み合わせる前提を最小化し、単一の世代（または世代集合）で復旧を完結させやすい点が特徴となる。
目的は、障害や事故が発生した際に、必要な復旧手順を単純化し、復元作業の見落としや手順依存を減らすことにある。また、運用者が扱いやすい復旧単位を用意することで、復旧時間の予測可能性を高める役割も担う。
1.2 他方式（増分・差分）との違い
1.2.1 復旧時の必要データ範囲の違い
完全バックアップでは、ある時点の状態に到達するための参照データが比較的明確になりやすい。リストアに必要な範囲は、基本的にその完全世代に対応するデータ一式を指す。増分方式では複数のバックアップ（基準世代＋以後の増分）を段階的に適用する必要が生じやすく、差分方式でも「基準世代＋特定期間の差分」など参照数が増える傾向がある。
結果として、完全バックアップは復旧時のデータ参照が短くなりやすく、手順の複雑さが緩和される。
1.2.2 容量・時間・運用負荷の違い
完全バックアップは、毎回「全量」を扱うため、保存容量と取得時間の見積りが増加しやすい。加えて、バックアップ先へ書き込むデータ量も大きくなり、ネットワーク転送やストレージI/Oへの負担が増える場合がある。
一方で、増分・差分は変更量に応じて転送・保存が抑えられることが多いが、復旧側では適用順序や欠損世代の影響が顕在化しやすい。したがって、完全方式は「取得コストを払って復旧を単純にする」性格が強い。
1.3 対象範囲の考え方
1.3.1 ファイル単位
対象をファイルやフォルダとして選び、所定のディレクトリツリーを丸ごと回収する考え方がある。ファイル単位は、アプリケーションデータの範囲を理解しやすい反面、構成ファイルや依存関係が複数ディレクトリにまたがる場合、整合性維持の設計が重要になる。
1.3.2 ディスク／ボリューム単位
ディスク全体やボリューム単位で取得し、ファイルシステム情報も含めた形で復元する方法である。ファイル単位よりも復元の流れが一定化しやすく、同一ボリュームの再構築に適する。特定ボリュームが障害を起こしたときの影響範囲を切り分けやすいが、無関係データまで含めやすく容量面の増大につながる。
1.3.3 システム全体（イメージ）単位
OSやブート領域などを含む全体像（イメージ）として取得する考え方である。災害復旧や移行の文脈で扱われることが多く、復旧を「展開」に近づけられる。反面、ハードウェアや仮想化環境の違いが復元後の起動可否に影響する場合があり、互換性評価が不可欠になる。
2 完全バックアップの仕組み
2.1 取得プロセス
2.1.1 スナップショットと一貫性
オンライン取得と整合性確保
稼働中のシステムで完全バックアップを行う場合、書き込みが進行するデータをそのまま読み出すと、同一時点として成立しない可能性がある。これを抑えるためにスナップショット技術を用い、ある時刻の状態を仮想的に切り出してから読み取る構成が採られる。
整合性確保の観点では、ファイル単体の整合に加えて、アプリケーションが持つ内部状態（トランザクション、キャッシュ、参照関係）も考慮する必要がある。バックアップ製品や基盤が提供する整合性モード（整合性保証のための待機や協調）を利用することで、復元後に不整合が表面化するリスクを下げられる。
2.2 アーカイブ形式と格納方式
2.2.1 物理イメージ形式
ディスクやボリュームの内容を、展開可能な形でまとめて保持する方式である。復元ではイメージの展開により、ボリュームの状態を再現する。オペレーティングシステムの起動を含む復旧に向きやすく、環境差を吸収する仕組みがない場合は移行時の制約が増える。
2.2.2 アーカイブ形式（ファイルとして固める方式）
スナップショットから得たファイル群やディレクトリを、ひとまとまりのアーカイブに格納する方式である。復元は展開処理により進むため、ファイルの追加・除外が必要になった際にも比較的柔軟に対応できる場合がある。反面、メタデータの扱い（属性、権限、タイムスタンプ、シンボリックリンク等）や、長いパスへの対応など、周辺仕様の整備が必要になる。
2.3 圧縮・重複排除の扱い
2.3.1 圧縮による容量削減
取得データを圧縮して保存効率を高める方法である。保存容量の削減に直結しやすいが、圧縮・展開時の計算負荷が増えるため、取得時間や復元時間へ影響が出る。圧縮アルゴリズムの選択や設定値は、CPU余力、復旧要件、同時実行数といった条件と整合させる必要がある。
2.3.2 重複排除による実効容量の最適化
同一内容の繰り返しを検出して重複部分を保存しないことで、実効容量を抑える技術である。完全バックアップでも、未変更領域や同一生成物が多い場合には効果が出る。導入形態としては、ファイル単位あるいはブロック単位での比較が用いられることがある。重複排除はメタデータ管理を伴うため、整合性検証や障害時の参照設計も重要になる。
2.4 暗号化と鍵管理
2.4.1 伝送中の保護
バックアップデータがネットワーク経由で送信される場合、盗聴や改ざんに備え、通信路の暗号化を行う。さらに、転送前後でデータが保存される経路がある場合には、保管中の暗号化と組み合わせる設計が望ましい。伝送中の保護は、鍵の配布経路や失効手順の整合性にも左右される。
2.4.2 保存データの保護
保存先に格納されるバックアップデータは、暗号化して不正取得に備える。暗号化方式としては、データ暗号化キーと鍵暗号化キーを分離し、鍵管理を中央化する構成が採られることがある。鍵の漏えい対策だけでなく、誤って削除やローテーションが進んだ場合に復元不能になるため、ライフサイクル管理が要点になる。
2.5 メタデータ（目録）の管理
2.5.1 ファイル属性と復元順序
アーカイブ形式では、ファイル属性や関連情報を目録に含め、復元時の順序や権限設定を支える。ディレクトリ作成、リンクの復元、タイムスタンプ反映など、復元段階で必要となる情報が欠けると、復元の品質に影響が出る。イメージ形式でも、展開に必要な領域情報やブロック対応がメタデータとして機能する。
2.5.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 リモート保管
別拠点のストレージやクラウドに保存する方法で、単一障害への耐性を高める。転送帯域や回線の安定性が運用成否を左右するため、データ量に対する送信時間と、混雑時の遅延見込みを織り込む必要がある。暗号化や認証を適切に行うことで、保管先のリスクも分離できる。
3.3.3 オフライン保管
取得したデータを、通常運用から切り離した状態で保持する考え方である。ランサムウェア等の影響を受けにくいという利点がある一方、更新手順や復元時の準備に手間がかかりやすい。オフライン化の運用頻度と復旧速度のバランスを設計する。
3.4 リカバリ要件から逆算する設計
3.4.1 RTO（復旧目標時間）
障害から復旧までに許容される時間を指す。完全バックアップは復元手順を短くできる場合があり、RTOを押さえる設計に寄与する。もっとも、データ転送が必要な場合や検証工程が含まれる場合には、実測に基づく見積りが重要になる。
3.4.2 RPO（許容データ損失）
失われてもよいデータ量、すなわち過去何時間分（または何世代分）まで戻せるかを示す。完全バックアップの頻度がRPOに直結しやすいため、更新頻度が高い領域では高頻度が求められることがある。ただし、容量と時間の制約があるため、要件に合う最小限の頻度を選定する。
3.5 失敗時の運用（監視・再実行）
3.5.1 ジョブ監視とアラート
バックアップジョブは成功／失敗だけでなく、速度低下、途中停止、整合性チェックの警告なども検知対象になる。監視は目録更新の確認や、保存先到達率、暗号化・転送の完了状態まで含めると、見逃しを減らせる。アラートは一次担当が判断できる形で通知し、対応手順が参照できるようにする。
3.5.2 リトライと整合性の確認
失敗時には再実行するだけでなく、原因が一過性か構造的かを切り分ける必要がある。再実行時に前回の中途世代が残る場合は、目録や世代管理との整合を確認する。復元が可能であることを示すため、世代ごとの整合性検証（チェックサム、復元テストの一部実施など）を定期的に行う運用が有効になる。
4 復元（リストア）と検証
4.1 復元手順の基本
4.1.1 全体復元
全体復元では、完全世代に対応するデータ一式を復元し、システム状態を目標時点に戻す。アーカイブ形式なら展開、イメージ形式なら展開または上書き復元の手順が中心となる。復元前には対象ディスクの状態、既存データとの衝突（上書き範囲）、必要な権限を整理する。
4.1.2 部分復元（必要時）
完全バックアップであっても、運用上は特定ファイルの戻しが必要になる場合がある。アーカイブ形式ではファイル単位の取り出しが行いやすいことがあるが、暗号化された場合は復号が必要になる。部分復元は便利だが、復旧目的（障害復旧か、削除誤りの解消か）に応じて整合性評価の範囲を決める。
4.2 復元先の選定
4.2.1 同一環境への復元
同一ホスト、同一構成に復元する場合、互換性の問題が比較的少なく、起動やアプリ動作に関する不確実性が下がりやすい。ストレージ配置やネットワーク設定も既知であるため、手順化しやすい。とはいえ、依然として暗号鍵、目録、メタデータの一致が必要である。
4.2.2 別環境への移行（互換性）
別環境への復元では、OS構成、ドライバ、仮想化設定などの違いが影響する。イメージ形式では特に起動周りの整合が問題になりやすい。移行可能性を高めるには、復元先の前提条件（最小要件、ネットワーク設定方式、ストレージコントローラの互換）を事前に定義し、移行テストを繰り返す。
4.3 動作検証・リストアテスト
4.3.1 ファイル単位の検証
復元テストでは、復元後のファイルが期待通りの内容であるかを確認する。チェックサム比較やサイズ・属性確認、必要に応じてアプリが参照する主要ファイルの整合性を確認する。部分復元の検証も、誤って復元対象を見誤らないための手順確認として意味を持つ。
4.3.2 起動・疎通の検証
システムを復旧する場合には、サービスが立ち上がり、ネットワーク経由の疎通が成立することが重要である。復元後に依存サービスや認証設定が反映されているかを含め、最低限の稼働条件を満たすかを確認する。時間を節約するために常時全量テストを行えない場合、クリティカル機能に絞った検証設計が採られる。
4.3.3 定期テストの実施方法
定期テストは、全世代を毎回検証する必要はなく、保持期間やリスクに応じてサンプリングする設計が一般的である。ただし、世代が増えるほど復元手順の前提が変化しやすいため、少なくとも主要な構成変更の後では実施頻度を上げる。検証結果は記録し、失敗要因を次回運用に反映する。
4.4 よくある障害と対処
4.4.1 バックアップ破損
取得途中の中断や保存先の不整合により、復元不能または破損が生じる場合がある。対処としては、まず目録の整合性、次に暗号化や圧縮の設定一致、最後に復元テスト結果を確認する。破損が再発する場合は、ストレージ障害やネットワーク品質の見直しを行う。
4.4.2 暗号鍵不一致
復元時に用いる鍵が一致しないと、復号不能となり復元できない。鍵のローテーション、管理システムの設定変更、誤った鍵セットの適用などが原因になりうる。対処は、世代ごとの鍵参照情報を確認し、必要な鍵を復元環境に正しく提供することである。鍵を失う可能性を抑えるには、鍵保持と世代保持を連動させる設計が重要になる。
4.4.3 世代の誤削除
保持ポリシーの設定ミスや手動操作の誤りにより、必要な世代が削除されると復元が成立しない。対処は、直ちに削除ログと目録を照合し、代替世代の可用性を確認することにある。再発防止として、削除権限の制限、承認フロー、依存関係の事前検査を組み込む。
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 1回あたりの容量
保存容量は、対象データ量に対してメタデータ、圧縮率、重複排除の効果、暗号化によるオーバーヘッド（ヘッダや鍵情報）を加味して見積もる。完全バックアップは全量寄与が大きいため、見積りの基礎データは実測に基づくことが望ましい。増加傾向がある場合は将来の伸びも含める。
6.1.2 世代保持による累積
世代数や保持期間が増えると、累積コストが線形またはそれ以上に増えることが多い。圧縮や重複排除で実効容量が抑えられても、世代ごとの新規領域が増えれば再び上昇する。最適化では「必要過去幅」と「保持条件」を同時に調整する。
6.2 ネットワーク負荷の管理
6.2.1 通信量の見積り
リモート保管では送信量がコスト要因になりやすい。通信量は、取得サイズ、圧縮の有無、転送方式（全量送信か差分的最適化があるか）によって変わる。トラフィックが増える時間帯を避けるため、通信量を曜日や時間帯で見積もる。
6.2.2 転送時間と帯域
転送時間は帯域幅と実効スループット（混雑、暗号化負荷、並列数）に左右される。ウィンドウ内に完了しない場合、次の処理に影響が波及する。必要に応じて同時実行数を調整し、回線の平均と最大の両方に対して余裕を見積もる設計が求められる。
6.3 バックアップ性能チューニング
6.3.1 同時実行数
同時に複数ジョブを走らせると、総転送量は増えるが、ストレージやCPUが飽和しやすくなる。チューニングでは、対象基盤のボトルネックを特定し、その上限を超えない範囲で並列度を決める。運用監視と組み合わせ、遅延の兆候を早期に検知する。
6.3.2 読み取り・書き込みの最適化
読み取り側ではキャッシュやI/Oスケジューラの影響を受けるため、優先度やスレッド設定を調整することがある。書き込み側は保存先の性能（受信処理、書き込み待ち、メタデータ更新）で決まることが多い。最適化では設定変更の影響範囲を切り分け、段階的に評価する。
6.4 圧縮・暗号化・検証のトレードオフ
6.4.1 CPU負荷と時間
圧縮と暗号化は計算処理を伴うため、CPU負荷と処理時間が増えることがある。処理時間の増加はバックアップウィンドウの逼迫や失敗率の上昇につながるため、優先順位を調整する必要がある。リソースが余っている領域では高い設定、余裕がない領域では抑制するなど、環境に合わせて配分する。
6.4.2 検証頻度の調整
検証（チェックサムや復元テストの一部）は信頼性を高めるが、追加の時間を要する。毎回の全量検証はコストが大きいため、世代の重要度や変更規模に応じて頻度や範囲を設計する。例えば主要な更新直後や鍵ローテーション後のみ深い検証を行うなど、リスクに応じた運用が合理的となる。