DR計画の策定
DR（災害復旧）計画の策定
DR（Disaster Recovery）計画とは、災害やシステム障害が発生した際に、ITシステムを迅速に復旧するための事前計画です。バックアップがデータの保護に焦点を当てるのに対し、DR計画はシステム全体の復旧プロセスを網羅する、より包括的な取り組みです。
災害の種類と影響分析
DR計画を策定する前に、まず自社が直面しうる災害を洗い出し、その影響を分析します。
| 災害の種類 | 具体例 | 影響範囲 | 復旧難易度 |
|---|---|---|---|
| 自然災害 | 地震、台風、洪水、火災、落雷 | 建物・設備全体 | 高 |
| インフラ障害 | 長時間停電、回線断、空調故障 | サーバールーム全体 | 中〜高 |
| サイバー攻撃 | ランサムウェア、標的型攻撃、DDoS | システム全体 | 中〜高 |
| ハードウェア障害 | サーバー故障、ストレージ障害、ネットワーク機器故障 | 個別システム | 低〜中 |
| ソフトウェア障害 | OS障害、DB破損、アプリケーションバグ | 個別システム | 低〜中 |
| 人為的災害 | 設定ミスによるデータ消失、内部犯行 | 個別〜全体 | 中 |
RTO/RPO目標の設定方法
DR計画の核となるのが、システムごとのRTO/RPO目標の設定です。設定手順は以下のとおりです。
- 業務プロセスの洗い出し：全社の業務プロセスとそれを支えるITシステムを一覧化
- 停止時の影響度評価：各システムが停止した場合の業務への影響（売上損失、顧客影響、法的リスク等）を評価
- 許容停止時間の合意：経営層と「このシステムは最大何時間止まっても許容できるか」を合意（これがRTO）
- 許容データ損失の合意：「最大何時間分のデータを失っても許容できるか」を合意（これがRPO）
- コストとのバランス：RTOを短く、RPOを小さくするほどコストが上がるため、ビジネス価値とのバランスを取る
📋 具体例
製造業の中小企業の例：
・生産管理システム：RTO=4時間、RPO=1時間（生産ラインが停止するため最優先）
・販売管理システム：RTO=8時間、RPO=4時間（翌営業日開始までに復旧）
・メールシステム：RTO=2時間、RPO=0（Microsoft 365利用で冗長性確保済み）
・社内ポータル：RTO=24時間、RPO=24時間（業務継続に直接影響しない）
DR環境の選択肢
| DR環境 | 概要 | RTO目安 | コスト |
|---|---|---|---|
| ホットサイト | 本番環境と同等のシステムが常時稼働。リアルタイムでデータ同期 | 数分〜1時間 | 非常に高い |
| ウォームサイト | ハードウェアは用意されているが、データの反映にタイムラグがある | 数時間〜1日 | 中程度 |
| コールドサイト | 場所と電源・回線のみ用意。機器搬入・セットアップから始める | 数日〜1週間 | 低い |
| クラウドDR | クラウド上にDR環境を構築。使用時のみリソースを起動 | 数分〜数時間 | 従量課金（比較的安い） |
ポイント：中小企業にとってホットサイトは現実的ではありません。クラウドDRが最もコストパフォーマンスに優れた選択肢です。平常時は最小限のコストで維持し、災害時にクラウドリソースをスケールアップして復旧するアプローチが現実的です。
クラウドDR（AWS/Azure）
主要クラウドプロバイダーが提供するDRサービスを活用すれば、中小企業でも高度なDR環境を構築できます。
| サービス | 概要 | 特徴 |
|---|---|---|
| AWS Elastic Disaster Recovery | オンプレミスのサーバーをAWSにレプリケーション | 継続的なレプリケーション、数分でフェイルオーバー可能 |
| Azure Site Recovery | VMware/Hyper-V環境をAzureにレプリケーション | Hyper-V環境との親和性が高い、テストフェイルオーバー機能 |
| Veeam Cloud Connect | Veeamバックアップをクラウドに転送 | 既存のVeeam環境とシームレスに連携 |
復旧優先順位の決定
すべてのシステムを同時に復旧することは不可能です。以下の優先順位で復旧を進めます。
- 第1優先：インフラ基盤（ネットワーク、Active Directory、DNS、DHCP）
- 第2優先：基幹業務システム（ERP、生産管理、販売管理）
- 第3優先：コミュニケーション基盤（メール、チャット、電話）
- 第4優先：業務支援システム（ファイルサーバー、印刷環境）
- 第5優先：その他（社内ポータル、開発環境等）
⚠️ 注意
Active DirectoryやDNSが復旧しない限り、他のほぼすべてのシステムは正常に動作しません。基幹業務システムを最優先にしたくなりますが、まずインフラ基盤の復旧が先であることを忘れないでください。復旧順序を間違えると、二次障害を引き起こす可能性があります。
ひとり情シスの視点：DR計画は壮大なものを目指す必要はありません。まずは「自社のサーバールームが使えなくなったら、どうやって業務を継続するか」というシンプルな問いから始めましょう。クラウドDRの無料枠やトライアルを活用して、小さく始めることが大切です。
✅ 完了済み