ITインフラ障害に備える：バックアップ・構成情報・連絡先の点検リスト

共有フォルダーが開かない。業務システムに入れない。インターネットにつながらない。障害が起きてから「構成図はどこか」「保守契約は誰が持っているか」を調べ始めると、原因の確認に取りかかるまでにも時間が必要です。

平時に用意しておきたいのは、機器の点検記録に加えて、復旧の判断に使える情報です。社内のIT担当者や他の業務と兼任している方が確認できる項目をまとめます。自社で止まると困る業務から、順番に確認してください。

1. 「何を、いつまでに戻すか」を業務側と決める

重要な業務を三つ程度書き出します。受注、出荷、会計などの業務名に、使用するシステムと責任者を添えてください。そのうえで、次の質問に答えます。

• その業務が止まると、誰に、どのような影響が出るか。
• いつまでに、どの範囲が使える状態に戻ればよいか。
• データは、どの時点まで戻せれば業務を再開できるか。
• 紙や電話などで一時的に続けられる仕事はあるか。

「当日中に出荷を再開したい」「前日分まで戻した場合は当日分の再入力が必要」といった書き方で構いません。希望だけで決めず、現行のバックアップや復元作業で実現できるか、管理担当者と確認します。

復旧までの目標時間をRTO、どの時点のデータまで戻すかという目標をRPOと呼びます。IPAも、業務継続の要件に合わせたバックアップと手順の整備、訓練による検証を示しています。出典：IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」第2部3（8）

2. バックアップは「最後に戻せた日」まで確認する

バックアップの実行結果と、復元して利用できた結果は分けて記録します。点検では、次の五点を確認してください。

1. 対象：必要なファイル、データベース、設定が含まれているか。
2. 日時：最後の成功日時と、失敗が続いていないか。
3. 保存先：本体が使えなくなっても、バックアップを取り出せるか。
4. 手順：誰が、何を使って、どこへ復元するか。
5. 検証：最後に復元した日、確認した内容、かかった時間。

共有フォルダーなら、検証用の別の場所へファイルを戻し、担当者が開けることまで確認します。業務システムではファイルが存在するだけでは足りません。製品の手順に沿って復元し、アプリケーションから必要なデータを読めるか確かめます。Microsoftも、SQL Serverについてテスト環境への復元と整合性確認を案内しています。出典：Microsoft Learn「SQL Server データベースのバックアップと復元」

本番データを上書きしないよう、対象、復元先、実施時間、担当者を事前に決めてください。VMなどを起動する検証では、本番と干渉しない環境も必要です。参考：Microsoft Learn「Hyper-V レプリカの概要」

バックアップ自体が攻撃や誤操作で失われない保管方法も確認します。オフライン保管や、一定期間変更・削除を制限する仕組みなど、環境に合う方法を検討してください。参考：Microsoft Learn「ランサムウェアから保護するためのバックアップと復元の計画」

3. 構成情報を「他の人がたどれる状態」にする

細かな設計書を一度に作る必要はありません。まず業務システムから、利用するサーバー、ネットワーク機器、回線までを簡単な図にします。仮想サーバーなら、どの物理サーバーやストレージに載っているかも記載します。

• 機器名、役割、設置場所、メーカー、型番。
• 管理担当者と保守窓口、契約番号、契約の有効期限。
• 設定の控えと操作手順の保管場所、最終更新日。
• 管理用アカウントを利用するための社内手続き。

パスワードや秘密鍵をこの一覧へ直接書き込まないでください。管理情報の保管先と、利用できる担当者を明確にします。停止したサーバーの中にしか構成図がない状態も避けます。閲覧者を制限した別の保管先など、障害中でも参照できる方法を用意してください。

図と実物が一致しない箇所は推測で埋めず「未確認」とします。次に保守担当者へ確認する内容が、そのまま整理できます。

4. 点検記録には、変化と次の対応を書く

日常点検では「正常」のチェックだけでなく、前回からの変化を残します。バックアップ失敗の日時、空き容量の推移、機器の警告表示、処理時間が延び始めた日などです。

空き容量や負荷の判定値は、役割や製品要件で変わります。「何％なら安全」と一律に決めず、保守担当者と確認対象、通知条件、通知を受ける人を決めます。通知後に誰も確認しない状態も見直す対象です。

更新作業では、サポート状況、既知の問題、検証方法、問題が出た場合の戻し方を確認します。点検のついでに本番設定を変えたり、理由の分からない警告を消したりせず、変更作業として担当者と予定を分けてください。

5. 連絡先と引継ぎメモを、障害中でも使えるようにする

連絡先には電話番号だけでなく、受付時間、対象機器、契約上の対応範囲を記載します。社内の判断者と代行者、メールや社内チャットが使えない場合の連絡方法も決めておきます。

• 発生日時、最後に正常だった日時。
• 止まっている業務、影響する拠点・人数、使えるもの。
• エラーと、直前の変更内容。
• 実施済みの操作、その時刻、結果。
• 優先して戻したい業務と、社内の判断者。

これは原因を断定する書類ではありません。確認できた事実と、まだ分からないことを分けて渡すためのメモです。写真や画面には、顧客情報や認証情報が写り込まないよう注意します。

点検結果を、次の一件につなげる

項目を「確認済み」「未確認」「要対応」に分け、未確認と要対応の項目に担当者と期限を付けます。重要業務のバックアップを復元したことがない、障害中に連絡先を取り出せない、といった状態は優先して見直してください。

担当者が不在の想定で、別の人が資料を探し、連絡先と復旧の優先順位を説明できるか試します。機器を止めなくても、資料の不足や引継ぎの難しさは確認できます。大きな構成変更や担当者交代があったときにも同じ確認を行いましょう。

まずは重要な業務を一つ選び、そのバックアップ、構成情報、連絡先をそろえるところから始めてください。分からない項目が残った場合は、その一覧を添えてソルブネオへご相談ください。