SMB 向けの災害復旧計画: 避けられない事態からビジネスを守る

データを失った中小企業の 60% は 6 か月以内に閉鎖されています。 しかし、文書化されテストされた災害復旧計画を持っている中小企業は 23% のみです。災害を乗り越える企業は、災害を回避した企業ではなく、災害に備えた企業です。

このガイドは、基本的なバックアップ戦略からマルチリージョン フェイルオーバー アーキテクチャまでのすべてをカバーする、中小企業向けの実用的な災害復旧フレームワークを提供します。

重要なポイント

• DR 戦略を選択する前に RPO と RTO を定義します --- これらの数値がアーキテクチャと予算を決定します
• 3-2-1 バックアップ ルール (コピー 3 つ、メディア タイプ 2 つ、オフサイト 1 つ) が、許容される最小限のバックアップ戦略です
• テストされていないバックアップはバックアップではありません --- 四半期ごとにリカバリ訓練をスケジュールします
• DR コストは RTO 要件に比例して増加します: 24 時間 RTO のコストは 1 時間 RTO の 10%

---

リカバリ目標の定義

RPO (目標復旧時点)

時間内で測定された最大許容データ損失。 RPO が 1 時間の場合、最大 1 時間のデータの損失を許容できます。

RTO (目標復旧時間)

許容可能な最大ダウンタイム。 RTO が 4 時間の場合、ビジネスは最大 4 時間オフラインでも存続できます。

目標とビジネスへの影響の一致

---

バックアップ戦略

3-2-1 ルール

• すべての重要なデータセットの 3 コピー
• 2 の異なるストレージ タイプ (ローカル ディスク + クラウドなど)
• 1 地理的に離れた場所にコピー

自動化された PostgreSQL バックアップ

#!/bin/bash
# /opt/scripts/backup-database.sh
# Run via cron: 0 */6 * * * /opt/scripts/backup-database.sh

set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/opt/backups/database"
S3_BUCKET="s3://ecosire-backups/database"
DB_NAME="ecosire"
DB_USER="app"
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Create backup with compression
echo "Starting backup at $(date)"
pg_dump -h localhost -U "$DB_USER" -Fc "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Verify backup integrity
pg_restore --list "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" > /dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "ERROR: Backup verification failed"
  exit 1
fi

BACKUP_SIZE=$(du -h "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" | cut -f1)
echo "Backup created: ${BACKUP_SIZE}"

# Upload to S3 with server-side encryption
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "$S3_BUCKET/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256

# Upload to secondary region
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "s3://ecosire-backups-dr/database/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256 \
  --region eu-west-1

# Clean up local backups older than retention period
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete

echo "Backup complete at $(date)"

アプリケーション ファイルのバックアップ

#!/bin/bash
# Backup application files, uploads, and configuration

TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Backup Odoo filestore
tar czf "/opt/backups/files/filestore_${TIMESTAMP}.tar.gz" /opt/odoo/data/filestore/

# Backup uploaded documents
tar czf "/opt/backups/files/uploads_${TIMESTAMP}.tar.gz" /opt/app/uploads/

# Backup configuration (secrets excluded)
tar czf "/opt/backups/config/config_${TIMESTAMP}.tar.gz" \
  --exclude='*.env*' \
  --exclude='*.pem' \
  /opt/app/infrastructure/

# Upload all to S3
aws s3 sync /opt/backups/ s3://ecosire-backups/ --sse AES256

---

フェイルオーバー アーキテクチャ

階層 1: コールド スタンバイ (RTO: 4 ～ 24 時間)

• クラウドストレージに保存されたバックアップ
• リカバリには、新しいインフラストラクチャのプロビジョニングとバックアップからの復元が含まれます
• 最も安価なオプション: ストレージの料金のみを支払います
• 重要ではない内部アプリケーションに適しています

階層 2: ウォーム スタンバイ (RTO: 1 ～ 4 時間)

• スタンバイサーバーは実行中だがトラフィックを受信していない
• データベースのレプリケーションにより、スタンバイ データが最新の状態に保たれます
• リカバリにはスタンバイの促進と DNS の更新が含まれます
• 中程度のコスト: サイズを縮小したスタンバイ サーバーの料金を支払う

Primary (active) ----replication----> Standby (warm)
                                         |
                   On failure: promote + DNS update

階層 3: ホット スタンバイ (RTO: <30 分)

• アクティブ/パッシブまたはアクティブ/アクティブ構成
• ヘルスチェックによる自動フェイルオーバー
• 同期レプリケーションを備えたデータベース
• 高コスト: 完全な重複インフラストラクチャの料金を支払う

                     Health Check
                         |
Load Balancer ------> Primary (active)
       |
       +-------------> Secondary (hot standby, auto-promote)

階層 4: マルチリージョン アクティブ/アクティブ (RTO: <5 分)

• 複数のリージョンが同時にトラフィックを処理します
• 地理別のグローバル ロード バランサー ルート
• マルチマスター書き込みのデータベース競合解決
• 最高のコストと複雑さ

コストの比較

---

回復テスト

四半期ごとの回復訓練

四半期ごとに、完全回復テストを実行します。

1. 過去 30 日間の ランダム バックアップを選択
2. 回復インフラストラクチャのプロビジョニング (運用環境とは別)
3. データベースをバックアップから復元
4. アプリケーション ファイルをバックアップから復元
5. Git から アプリケーション コードをデプロイ
6. 復元された環境に対して 煙テストを実行
7. RTO 目標に対する 実際の回復時間を測定
8. 調査結果を文書化し、DR 計画を更新します

復旧訓練チェックリスト

• データベースはバックアップから正常に復元されました
• アプリケーションが開始され、リクエストが処理されます
• ユーザー認証が機能します
• 重要なビジネス フローが完了しました (注文、請求書の生成)
• 統合エンドポイントが応答します (支払いゲートウェイ、電子メール)
• 実際の回復時間は RTO 目標を満たしています
• チームはドキュメントを参照せずに自分の役割を理解している
• コミュニケーション チャネルは機能しています (関係者にどのように通知しますか?)

---

インシデント対応ハンドブック

重大度レベル

SEV1 対応手順

1. 15 分以内にインシデントを 承認してください
2. 範囲を 評価: 何が影響を受けるか、何人のユーザーが影響を受けるか
3. 関係者との コミュニケーション: ステータス ページの更新、顧客への通知
4. 利用可能な最も迅速なオプション (ロールバック、フェイルオーバー、スケーリング) を使用して 軽減
5. 根本原因を 解決
6. 48 時間以内の 事後分析: タイムライン、根本原因、アクション項目

---

よくある質問

災害復旧にはどれくらいの予算が必要ですか?

適切な DR 予算は、運用インフラストラクチャのコストの 10 ～ 25% です。インフラストラクチャに月額 500 ドルを費やす企業の場合、DR に月額 50 ～ 125 ドルの予算を立てます。これには、クラウド バックアップ ストレージ、ウォーム スタンバイ サーバー、監視が含まれます。 ROI の計算: ビジネスで 1 時間あたり 5,000 ドルのダウンタイムが発生し、DR によって潜在的な 24 時間の停止が 4 時間に短縮された場合、DR への投資により 100,000 ドルが節約されます。

マネージド クラウド プロバイダーを使用する場合、DR は必要ですか?

はい。クラウド プロバイダーは、ハードウェア障害やデータ センターの停止からは保護しますが、アプリケーションのバグ、誤った削除、ランサムウェア、アカウント侵害からは保護しません。 DR 計画では、データの破損、リソースの削除、セキュリティ侵害、ベンダー ロックインのリスクなど、クラウド プロバイダーが対応していないシナリオをカバーする必要があります。

Odoo ERP システムの DR はどのように処理すればよいですか?

Odoo DR には 3 つのコンポーネントが必要です: (1) PostgreSQL データベース バックアップ (自動、暗号化、オフサイト)、(2) ファイルストア バックアップ (アップロードされた添付ファイル、レポート テンプレート)、(3) カスタム モジュール コード (Git)。リカバリには、サーバーのプロビジョニング、Odoo のインストール、データベースの復元、ファイルストアの復元、カスタム モジュールの展開が含まれます。 ECOSIRE は、自動バックアップとテスト済みの回復手順を備えた マネージド Odoo DR を提供します。

最も一般的な DR 障害は何ですか?

未テストのバックアップ。バックアップの復元の 30% 以上が、破損、不完全なバックアップ、依存関係の欠落、またはパスワードの変更により失敗します。 2 番目に多い失敗は、ドキュメントが古いことです。DR 計画で参照されているサーバー、資格情報、またはもう存在しない手順が挙げられます。四半期ごとのテストでは両方の問題が見つかります。

---

次に何が起こるか

災害復旧は運用の回復力の 1 つの柱です。これを、早期検出のための 監視とアラート、安全な変更のための ゼロダウンタイム展開、脅威防止のための セキュリティ強化 と組み合わせます。

災害復旧の計画と実装については ECOSIRE にお問い合わせ、完全なインフラストラクチャ ロードマップについては DevOps ガイド をご覧ください。

---

ECOSIRE が発行 -- 企業が避けられない事態に備えるのを支援します。