バックアップが3ヶ月間失敗していた

監視不足によりバックアップジョブが3ヶ月間失敗し続けていたことが発覚した事例について、発見から影響調査、復旧、監視体制の強化までをひとり情シスの視点で解説します。

状況：バックアップが3ヶ月間取れていなかった

ファイルサーバーの空き容量を確認するために管理画面を開いたところ、ふとWindows Serverバックアップのステータスが目に入りました。最終バックアップ成功日が3ヶ月前の日付を示しています。バックアップジョブは毎日深夜2時に自動実行される設定ですが、ログを確認すると3ヶ月前から毎晩「失敗」のステータスが記録されていました。

つまり、この3ヶ月間、ファイルサーバーのバックアップが一切取れておらず、もしこの間にランサムウェア感染やハードウェア故障が起きていたら、3ヶ月分のデータが完全に失われていたことになります。冷や汗が出る瞬間です。

⚠️ 注意

「バックアップは設定したら安心」という考えは非常に危険です。バックアップジョブはさまざまな理由で静かに失敗し続けます。失敗してもエラー音が鳴るわけでもなく、誰にも通知されなければ、次にバックアップが必要になるまで（つまり実際にデータを失うまで）誰も気づきません。バックアップの成功確認は最も重要なIT運用業務の一つです。

原因：なぜバックアップが失敗し続けたのか

直接的原因の調査

Windows Serverバックアップのログを詳細に確認すると、以下のエラーメッセージが記録されていました。

📋 具体例

エラーログの内容：
「ボリュームシャドウコピーサービスのエラー: バックアップ先のディスクに十分な空き領域がありません。」

3ヶ月前に大量のデータ（約500GB）がファイルサーバーに追加されたことで、バックアップ先の外付けHDD（2TB）の容量が不足し、バックアップが完了できなくなっていました。バックアップ先の外付けHDDは1.9TB使用済みで、新しいフルバックアップを書き込む容量が残っていませんでした。

根本的原因の分析

直接的にはディスク容量の不足ですが、根本的な原因は以下の管理体制の不備です。

バックアップ成功の監視がなかった：バックアップジョブの成否を確認する仕組み（メール通知等）が設定されていなかった
定期的なバックアップ確認ルーチンがなかった：日常業務の中でバックアップ状態を確認する習慣がなかった
バックアップ容量の計画が不十分だった：データ増加に対するバックアップ容量の見積もりが甘かった
ドキュメントが未整備だった：バックアップの運用手順書が存在せず、属人的な管理になっていた

💡 ポイント

ひとり情シスあるあるの一つが「バックアップを設定したことに安心して、その後の監視を忘れる」です。セットアップ時は意識が高いのですが、日常業務に追われるうちにバックアップの存在自体を忘れがちです。バックアップは「取ること」よりも「取れていることを確認すること」の方が重要です。

対応フェーズ：バックアップの復旧

ステップ1：影響範囲の評価

まず、現在のリスク状態を正確に把握します。

最新のバックアップ時点：3ヶ月前（例：1月15日深夜）
バックアップ対象：ファイルサーバーの全共有フォルダ（約1.5TB）
失われるリスクのあるデータ：1月16日以降に作成・変更された全ファイル（3ヶ月分の業務データ）
他のバックアップの有無：クラウドバックアップ（Azure Backup）は正常に動作しており、週次で取得されていた → これが救い

📋 具体例

影響評価のマトリクス：
・ファイルサーバー日次バックアップ（外付けHDD）：3ヶ月間失敗 → 最新は1月15日時点
・クラウドバックアップ（Azure Backup）：正常動作中 → 最新は先週日曜日時点
・シャドウコピー（Volume Shadow Copy）：正常動作中 → 最新は今朝時点（ただし同一ディスク上なのでディスク故障時は使用不可）

→ クラウドバックアップが正常なため、最悪のケースでも先週日曜以降のデータ損失に限定される。ただし、ローカルバックアップの復旧は急務。

ステップ2：バックアップの即時復旧

バックアップが取れていない状態は「保険なしで運転している」のと同じです。即座にバックアップを復旧させます。

バックアップ先の容量を確保：外付けHDDの古いバックアップデータを整理し、最低限必要な世代数（直近3世代分）を残して削除
それでも容量不足の場合：より大容量の外付けHDD（4TB以上）を緊急購入
バックアップジョブを手動で実行し、正常に完了することを確認
翌朝、自動実行のバックアップが正常に完了していることを確認

⚠️ 注意

バックアップ先のHDDを入れ替える場合、旧HDDのバックアップデータはすぐに破棄しないでください。新しいHDDでバックアップが正常に動作し、最低1回のフルバックアップと1回の復元テストが完了するまで、旧HDDは保管しておきます。「唯一のバックアップ」を失うリスクを避けるためです。

ステップ3：バックアップの復元テスト

バックアップが「取れている」ことと「復元できる」ことは別問題です。新しいバックアップが正常に復元できることを必ず確認します。

テスト用のPCまたは仮想マシンを用意
最新のバックアップからテストフォルダ（数GB程度）を選んで復元
復元したファイルが正常に開けることを確認
ファイルのタイムスタンプとサイズが元データと一致することを確認

💡 ポイント

「バックアップは取れているが復元できない」という事態は珍しくありません。バックアップデータの破損、バックアップソフトのバージョン不一致、復元手順の誤りなど、復元時に初めて発覚する問題が多くあります。四半期に1回は復元テストを実施する習慣を持ちましょう。復元テスト自体は30分程度で完了します。

監視体制の強化：二度と見逃さない仕組み作り

ステップ4：バックアップ成否のメール通知を設定する

バックアップジョブの成功・失敗をメールで自動通知する仕組みを構築します。

方法1：Windows Serverのタスクスケジューラ + PowerShell

バックアップジョブの完了後にPowerShellスクリプトを自動実行し、結果をメール送信します。

📋 具体例

PowerShellスクリプト例（バックアップ結果をメール送信）：

$backupStatus = Get-WBSummary
$lastResult = $backupStatus.LastBackupResultHR
$lastTime = $backupStatus.LastSuccessfulBackupTime

if ($lastResult -ne 0) {
  $subject = "【警告】バックアップ失敗 - ファイルサーバー"
  $body = "ファイルサーバーのバックアップが失敗しました。`n最後の成功: $lastTime`nエラーコード: $lastResult`n至急確認してください。"
} else {
  $subject = "【正常】バックアップ成功 - ファイルサーバー"
  $body = "ファイルサーバーのバックアップが正常に完了しました。`n完了時刻: $lastTime"
}

Send-MailMessage -From "backup@example.co.jp" -To "admin@example.co.jp" -Subject $subject -Body $body -SmtpServer "smtp.example.co.jp"

このスクリプトをタスクスケジューラで毎朝7時に実行すれば、出社時にバックアップ結果のメールが届きます。

方法2：監視ツールの導入

より本格的な監視には、以下のツールが有効です。

Zabbix（無料）：サーバーの各種メトリクス（CPU、メモリ、ディスク、バックアップ状態）を一元監視。アラートメールやSlack通知が可能
PRTG Network Monitor（100センサーまで無料）：GUIが直感的で導入しやすい。バックアップソフトの監視センサーも用意されている
Windows Admin Center（無料）：Microsoftの管理ツール。Windows Serverの状態をWebブラウザから監視可能

ステップ5：バックアップ監視の日常ルーチン化

自動通知に加え、日常のルーチンとしてバックアップ確認を組み込みます。

毎朝（出社直後）：バックアップ結果の通知メールを確認。成功メールが届いていない場合は即調査
毎週金曜：バックアップ先ディスクの空き容量を確認。80%以上使用している場合は容量拡張を検討
毎月初：バックアップ対象のデータ量の推移を記録。急増していないか確認
四半期に1回：バックアップの復元テストを実施

📋 具体例

バックアップ確認チェックシート（毎朝の確認用）：

□ ファイルサーバー日次バックアップ：成功 / 失敗
□ クラウドバックアップ（週次）：成功 / 失敗 / 今週は未実行
□ バックアップ先ディスク空き容量：____GB / ____GB（____%使用）
□ 特記事項：

このチェックシートをデスクに置いておき、毎朝チェックするだけでも大きな効果があります。3分あれば完了します。

ステップ6：バックアップ容量の計画的管理

今回の失敗の直接的原因は容量不足でした。再発防止のため、以下の容量管理を行います。

バックアップ先の容量は、対象データの3倍以上を確保（フルバックアップ3世代分）
データ増加ペースを月次で記録し、バックアップ先の容量不足を事前に予測
バックアップの保持ポリシーを明確にする（例：日次は7日分、週次は4週分、月次は12ヶ月分）
古いバックアップの自動削除を設定し、容量の自動管理を実現

💡 ポイント

ひとり情シスの視点で最も重要なのは、「バックアップの監視を自動化すること」です。毎朝メールで通知が届く仕組みさえ作れば、3分の確認で済みます。PowerShellスクリプトの設定に1時間かけるだけで、今後何年もの安心が手に入ります。バックアップが3ヶ月間失敗していて気づかないという事態は、たった1通の通知メールで防げたのです。

ステップ7：バックアップ運用手順書の作成

属人的な管理を防ぐため、バックアップの運用手順書を作成します。

手順書に含める内容

バックアップの対象と範囲
バックアップのスケジュール（日次・週次・月次）
バックアップ先のメディアと保管場所
バックアップ成功の確認方法
バックアップ失敗時の対応手順
復元手順（ファイル単位の復元・サーバー全体の復元）
バックアップ先ディスクの交換手順
復元テストの実施手順とスケジュール

⚠️ 注意

バックアップの運用を自分一人しか知らない状態は、「自分が病気や事故で不在の時にバックアップ関連のトラブルが起きたら誰も対応できない」ことを意味します。最低限、上長または同僚に手順書の存在と保管場所を共有し、緊急時に参照できるようにしておきましょう。

まとめ

バックアップは「設定して安心」ではなく、「取れていることの確認」が最重要
バックアップ失敗は通知の仕組みがなければ発見できない。メール通知を必ず設定する
バックアップ先の容量計画を怠ると、データ増加に伴い突然失敗し始める
復元テストを定期的に実施し、「バックアップは取れているが復元できない」事態を防ぐ
バックアップの運用を手順書化し、属人化を排除する