2026年10月10日

サーバーの障害復旧（DR）計画の作り方

バックアップ・監視

はじめに

DR（Disaster Recovery）計画とは「重大な障害が発生したとき、いつまでに・どの程度のデータ損失で復旧するか」を事前に取り決め、その実現手段と訓練を含めて整備したものです。バックアップを取るだけでは DR とは呼べません。「戻し方」と「戻る時間」までを含めて初めて、組織の事業継続を支える備えになります。

DR の中核となる2つの指標が RTO（Recovery Time Objective: 目標復旧時間） と RPO（Recovery Point Objective: 目標復旧時点） です。RTO は「どれくらいで再起動できるか」、RPO は「どこまでのデータを諦めるか」を表します。

本記事では Linux サーバー運用の現場で、最小限の労力で実効性のある DR 計画を作る手順を解説します。

症状・背景

DR 計画が必要になる場面:

データセンター丸ごとの障害（火災・水没・電源喪失）に備えたい
ランサムウェア被害からの復旧時間を経営層に説明したい
監査要件（ISMS, SOC2, 個人情報保護）で DR 文書の提出を求められた
担当者不在時でも他メンバーが復旧手順を実行できるようにしたい

手順・設定方法

ステップ1: RTO/RPO を決める

# RTO/RPO 検討テンプレート（テキストで管理可能）
sudo mkdir -p /etc/dr
cat <<'EOF' | sudo tee /etc/dr/rto_rpo.txt
[サービス] WordPressサイト
  RTO: 4時間（業務影響評価より）
  RPO: 1時間（直近1時間のコメント損失は許容）
[サービス] ECサイト
  RTO: 30分
  RPO: 5分（注文情報の損失は致命的）
[サービス] 社内Wiki
  RTO: 24時間
  RPO: 24時間
EOF

ステップ2: 復旧手順書をリポジトリで管理

# Git で DR 手順書を管理
cd /etc/dr
sudo git init
cat <<'EOF' | sudo tee /etc/dr/recovery-wordpress.md
# WordPress復旧手順
## 前提
- 復旧先: dr-vm.example.com
- バックアップ: s3://backup-bucket/wp/
## 手順
1. 復旧先VMに最新OSイメージをデプロイ
2. restic restore latest --target /var/www
3. mysql 復元: gunzip < dump.sql.gz | mysql wp
4. DNS切替: TTL 60秒に下げてからAレコード変更
5. SSL証明書再発行（certbot --nginx）
EOF
sudo git add -A && sudo git commit -m "DR runbook: WordPress"

ステップ3: コマンドベースで復旧をスクリプト化

# /usr/local/sbin/restore-wordpress.sh
cat <<'EOF' | sudo tee /usr/local/sbin/restore-wordpress.sh
#!/bin/bash
set -euo pipefail
export RESTIC_REPOSITORY="s3:https://s3.example.com/wp-backup"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"

echo "[1/4] 最新スナップショット復元"
restic restore latest --target /

echo "[2/4] MySQLリストア"
gunzip -c /backup/mysql-all.sql.gz | mysql

echo "[3/4] パーミッション復元"
chown -R www-data:www-data /var/www/html

echo "[4/4] Nginx再起動"
systemctl restart nginx php8.2-fpm
echo "復旧完了: $(date)"
EOF
sudo chmod 700 /usr/local/sbin/restore-wordpress.sh

ステップ4: 定期 DR 訓練の実施

# 4半期ごとに別VMで実復旧テスト
# 1. テスト用VMを作成（クラウドなら最安インスタンス）
# 2. 手順書通りに復旧
time /usr/local/sbin/restore-wordpress.sh

# 3. 計測結果を記録
echo "$(date +%F) RTO実測: 28分, データ最終時刻: $(stat -c %y /backup/wp/latest)" \
  | sudo tee -a /var/log/dr-drill.log

# 4. 想定との差分を手順書にフィードバック
cd /etc/dr && sudo git commit -am "drill: 2026Q2 actual RTO=28min"

注意事項

手順書は紙でも印刷物でも参照できるよう、別拠点にもコピーを置く
DR 訓練は本番に影響しない隔離環境で実施する
DNS の TTL は普段から短め（300秒以下）に設定しておくと切替が速い
パスワード・証明書・APIキー等は復旧後に再発行する前提で設計する

まとめ

1. RTO/RPO: 数値で合意し、コストと天秤にかける

2. 手順書: Git で版管理し、誰でも実行できる粒度に

3. 自動化: 反復可能なステップはスクリプト化

4. 訓練: 4半期ごとに実復旧を計測

5. 改善: 訓練結果を手順書に反映するループ