システム復旧の実践
システム復旧の実践
DR計画を策定しても、実際に復旧を実行できなければ意味がありません。ここでは、中小企業で運用される主要なシステムの具体的な復旧手順を解説します。
ベアメタルリストア
ベアメタルリストアとは、OS・アプリケーション・設定・データを含むシステム全体を、空のハードウェア(ベアメタル)に一括で復元する方法です。
Windows Server Backupでのベアメタルリストア手順
- 復旧用のWindows Serverインストールメディア(USBまたはDVD)で起動
- 「コンピューターを修復する」を選択
- 「トラブルシューティング」→「システム イメージ回復」を選択
- バックアップの保存先(外付けHDD、ネットワーク共有)を指定
- 復元するシステムイメージを選択し、復元を実行
- 復元完了後、再起動してシステムの動作を確認
⚠️ 注意
ベアメタルリストアは同一またはほぼ同一のハードウェアへの復元を前提としています。異なるハードウェアに復元する場合、ドライバーの互換性問題が発生する可能性があります。Acronisの「Universal Restore」やVeeamの「Sure Recovery」など、異種ハードウェア対応機能を持つツールを検討してください。
仮想マシン復旧
仮想環境(Hyper-V、VMware)の復旧は物理サーバーよりも柔軟性があります。
| 復旧方式 | 内容 | RTO |
|---|---|---|
| VMバックアップからの復元 | Veeam等でバックアップしたVMイメージを別ホストに復元 | 30分〜数時間 |
| レプリケーション | 別ホストにリアルタイムで複製したVMに切り替え | 数分 |
| Instant VM Recovery | バックアップファイルから直接VMを起動(Veeam機能) | 数分 |
| クラウドへの復元 | Azure Site Recovery等でクラウド上にVMを起動 | 15分〜1時間 |
📋 具体例
Veeam Backup & Replicationを使ったInstant VM Recoveryの流れ:
1. Veeamコンソールを開き「Restore」→「Instant VM Recovery」を選択
2. 復元するVMと復旧時点を選択
3. 復元先のHyper-V/ESXiホストを指定
4. 「Finish」をクリック→数分でVMが起動
この方法なら、バックアップストレージから直接VMが起動するため、復元完了を待たずに業務を再開できます。
Active Directory復旧
Active Directoryはほぼすべての社内システムの認証基盤であり、復旧の最優先対象です。
AD復旧の基本手順(DSRM: Directory Services Restore Mode)
- ドメインコントローラーをDSRM(ディレクトリサービス復元モード)で起動
- DSRMパスワードでログオン(通常のドメインアカウントは使用不可)
- Windows Server Backupからシステム状態(System State)を復元
- 通常モードで再起動し、レプリケーション状態を確認
- 他のDCとの整合性を
repadmin /showreplで確認
ポイント:DSRMパスワードは初期設定時に設定されますが、長期間変更されていないケースが多いです。年1回はntdsutilコマンドでDSRMパスワードを変更し、安全な場所に記録しておきましょう。復旧時にDSRMパスワードが分からないと復旧できません。
DNS復旧
DNSが機能しないと名前解決ができず、ほぼすべてのネットワーク通信が失敗します。
- AD統合DNS:ADの復旧に含まれる。ADが復旧すればDNSも自動的に復旧
- スタンドアロンDNS:DNSゾーンファイルのバックアップと復元が必要
- 復旧確認:
nslookupコマンドで主要なホスト名の名前解決を確認 - 暫定対応:DNSが復旧するまで、クライアントPCのhostsファイルに重要なサーバーのIPアドレスを手動追記して最低限の通信を確保
データベース復旧
データベースの復旧は、アプリケーションの種類によって手順が異なります。
| DB | バックアップ手法 | 復旧コマンド例 |
|---|---|---|
| SQL Server | 完全バックアップ+トランザクションログバックアップ | RESTORE DATABASE [DB名] FROM DISK = 'パス' WITH RECOVERY |
| MySQL/MariaDB | mysqldump、xtrabackup | mysql -u root -p DB名 < backup.sql |
| PostgreSQL | pg_dump、pg_basebackup | pg_restore -d DB名 backup.dump |
| Oracle | RMAN(Recovery Manager) | RMAN> RESTORE DATABASE; RECOVER DATABASE; |
⚠️ 注意
データベースの復旧後、アプリケーション側との整合性確認が必須です。特にトランザクションの途中で障害が発生した場合、データの不整合が発生している可能性があります。復旧後は必ずアプリケーション側の動作確認テストを実施してください。
復旧手順書の作成
復旧手順書は、災害時にパニック状態でも確実に作業を進められるよう、詳細かつ分かりやすく記述する必要があります。
手順書に含めるべき項目
- 前提条件:必要な機材、メディア、認証情報の一覧
- 復旧手順:スクリーンショット付きのステップバイステップ手順
- 確認事項:各ステップ完了後に確認すべき事項(チェックリスト形式)
- 連絡先:ベンダーサポート、クラウドプロバイダー、回線業者の緊急連絡先
- トラブルシューティング:想定されるエラーと対処法
- 復旧完了基準:何をもって復旧完了とみなすかの判定基準
📋 具体例
復旧手順書の保管場所も重要です。社内サーバーにだけ保存していると、そのサーバーが被災した際に手順書も失われます。以下の場所に多重保管しましょう:
・社内ファイルサーバー(通常時の参照用)
・クラウドストレージ(OneDrive、Google Drive等)
・印刷物(金庫に保管)
・担当者のスマートフォン(PDFを保存)
・遠隔地の拠点(別事務所等)
ひとり情シスの視点:復旧手順書は「自分が不在でも、ITに詳しくない同僚が読んで実行できる」レベルの詳細さを目指しましょう。自分が被災して動けない場合に備えて、外部のITベンダーや代行者が手順書を見て復旧できるようにしておくことが重要です。
✅ 完了済み