Skip to main content

第18章：“検証”が本体：復元テスト（DRごっこ）をやる🎭

バックアップって、取った瞬間は安心なんだけど… 本当に大事なのは「戻せること」なんだよね😇（ここができて初めて“保険”になる！）

この章では、安全に壊して→安全に戻して→ちゃんと動くか確認する、いわゆる DR（Disaster Recovery）ごっこ を“手順の型”として作ります🧯✨ （公式のボリュームバックアップ/リストア手順に沿って進めるよ） (Docker Documentation)

ねらい🎯（この章が終わるとできること）​

  • 「復元テストの型」が手元に残る📄✨（次も迷わない）
  • 別名ボリュームに復元して、今の環境を壊さず検証できる🧪
  • “動いた！”を判断する 確認チェックリスト が作れる✅

成果物はこれ👇

  • docs/dr-restore-test.md（復元テスト手順書）
  • compose.drtest.yml（検証用のCompose上書きファイル）

まず超ざっくり用語🧠✨​

  • RPO：どこまでデータ消えてOK？（例：最大1日分までなら許す📅）
  • RTO：どれくらいで復旧したい？（例：30分以内に戻したい⏱️）
  • Runbook（手順書）：焦っても読めば戻せる“台本”📘

ここ、設計超入門だとフワッとしがちだけど、DRごっこを1回やると一気に腹落ちするよ😆

DRごっこの全体像（安全第一）🦺​

ポイントはこれ👇 ✅ 現役ボリュームは壊さない ✅ 別名ボリュームに復元して起動 ✅ OKだったら「この手順で戻せる」が証明完了🎉

流れはこう👇

  1. 目印データを入れる（復元できたか分かる印）🏷️
  2. バックアップ取る🧳
  3. 別名ボリューム作る📦
  4. そこへリストアする🔁
  5. 検証用のComposeで起動する🚀
  6. 動作確認する✅
  7. 後片付け＆手順書更新🧹

ハンズオン：別名ボリューム復元テスト（tar方式）🧳➡️📦➡️✅​

ここでは「ボリュームを tar で固めたバックアップ」を復元テストします。 この流れ自体が公式の“ボリュームのバックアップ/復元”の考え方ど真ん中です (Docker Documentation)

以降、例として

  • 元のボリューム名：pgdata
  • テスト用ボリューム名：pgdata_drtest
  • バックアップファイル：backup.tar として書くね🙂（自分のプロジェクトに合わせて読み替えOK）

0) 目印データ（DRマーカー）を入れる🏷️🧪​

「復元できたか？」を一発で判断するために、DBへ“印”を置くよ。

例：Postgresならこんな感じ👇（サービス名が db の想定）

docker compose exec db psql -U postgres -d postgres -c "
CREATE TABLE IF NOT EXISTS dr_marker (
  id text PRIMARY KEY,
  created_at timestamptz DEFAULT now()
);
INSERT INTO dr_marker(id) VALUES ('DRTEST-2026-02-11-01')
ON CONFLICT DO NOTHING;
SELECT * FROM dr_marker ORDER BY created_at DESC LIMIT 5;
"

✅ DRTEST-... が表示されたらOK！ （この値が復元後にも出たら「戻せてる」ってこと🎉）

1) バックアップを取る🧳​

公式ドキュメントの流れは「一時コンテナで tar を作る」スタイル。 ここでは named volume を /dbdata にマウントして固めるよ (Docker Documentation)

mkdir -p backup
docker run --rm -v pgdata:/dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

✅ backup/backup.tar ができたらOK！

「バックアップ取ったのに、ボリュームの中身が含まれてない」事故、わりとある😇 そもそも “コンテナをイメージ化しても、ボリュームの中身は別物” って扱いだからね (Docker Documentation)

2) テスト用ボリュームを作る📦（空っぽ）​

docker volume create pgdata_drtest

3) テスト用ボリュームへリストアする🔁​

公式の復元例（tar xvf ... --strip 1）に寄せてやるよ (Docker Documentation)

docker run --rm --volumes-from "$(docker create -v /dbdata --name temp_restore ubuntu /bin/bash)" -v $(pwd):/backup ubuntu bash -c "cd /dbdata && tar xvf /backup/backup.tar --strip 1"
docker rm temp_restore

ただ、上の形は「一時コンテナを作って --volumes-from」なので、もっと素直に ボリューム名で直マウントしてもOK👇（理解しやすい）

docker run --rm -v pgdata_drtest:/dbdata -v $(pwd):/backup ubuntu bash -c "cd /dbdata && tar xvf /backup/backup.tar --strip 1"

✅ エラーなく終わればOK！

4) “復元したボリューム”で起動する🚀（上書きComposeを使う）​

ここがDRごっこのキモ😎 普段の docker-compose.yml は触らず、上書きファイルでDBだけ差し替える！

compose.drtest.yml を作る👇（例：DBサービス名が db）

services:
  db:
    volumes:
      - pgdata_drtest:/var/lib/postgresql/data

volumes:
  pgdata_drtest:
    external: true

external: true にすると、「その名前のボリュームが既にある前提」で使ってくれるよ（無ければエラーになるので安全） (Docker Documentation)

起動👇

docker compose -f docker-compose.yml -f compose.drtest.yml up -d

5) 動作確認する✅✅✅（ここが“本体”）​

最低限これだけはチェックしよう🙂 （アプリがあるなら「ログインできる」「一覧が出る」みたいなユーザー動線も入れると強い💪）

DBの印チェック🏷️

docker compose exec db psql -U postgres -d postgres -c "SELECT * FROM dr_marker ORDER BY created_at DESC LIMIT 5;"

コンテナ状態チェック🩺

docker compose ps
docker compose logs --tail=200 db

“いつもの確認”チェックリスト例✅

  • dr_marker が復元後も見える
  • DBコンテナが再起動ループしてない
  • アプリの主要APIが 200 を返す（2〜3本でOK）
  • 直近の重要データ（例：最新1件）が見える

コツ：確認は「全部」じゃなくていいよ🙂 “これが戻ってないと困る” だけを短く決めるのが設計の第一歩✨

6) 後片付け🧹（テストが終わったら消す）​

テスト用を落とす👇

docker compose -f docker-compose.yml -f compose.drtest.yml down
docker volume rm pgdata_drtest

失敗したときの“最短デバッグ”🧯🔍​

よくあるのはこの辺👇（あるあるすぎる😂）

  1. ボリューム名が違う
  • docker volume ls で存在確認👀
  • Composeの external: true は「無ければ即エラー」なので事故りにくい (Docker Documentation)
  1. 起動はしたけどデータが空
  • 目印データ（dr_marker）が入ってた“元バックアップ”を使ってる？🤔
  • バックアップ作成直後にテストするのが鉄板👍
  1. 権限/所有者でコケる（特に物理バックアップ系）
  • docker compose logs db を見る
  • ボリューム復元時に変な階層になってないか（--strip 1 付け忘れ等） (Docker Documentation)

もっとラクしたい人向け：GUIで“クローン”して検証🧰🖱️​

実は Microsoft のPCでも、Docker Desktop の Volumes 画面で ボリュームを Clone / Export / Import できる（機能が用意されてる）んだよね😳 (Docker Documentation)

  • CLIが怖いときの“保険”に便利✨
  • ただし一部操作は「サインインが必要」なものもある（Cloneなど） (Docker Documentation)

AI活用コーナー🤖✨（安全にね）​

GitHub Copilot や OpenAI 系のAIには、こう聞くと強い💪

  • 「このプロジェクトの“復元できた判定”のチェック項目を5つに絞って」
  • 「復元テスト手順を runbook 風に箇条書きにして」
  • 「失敗時の切り分けフロー（ログ→設定→データ）を作って」

⚠️ ただし、.env の中身や鍵やトークンは貼らないでね🔒（バックアップや復旧は秘密が混ざりやすい💥）

まとめ🏁✨（この章のゴール）​

  • バックアップは「取った」より “戻せた” が重要🎭
  • 別名ボリューム復元→起動→確認 の型ができれば、もう怖くない😆
  • 次章（自動化）に進む前に、まずこの“手順書”を1回完成させよう📘✅

必要なら、あなたの docker-compose.yml（DB周りだけでOK）を貼ってくれたら、あなたの構成に合わせた compose.drtest.yml とチェック項目に最適化して書き換えるよ🙂✨