第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だったら「この手順で戻せる」が証明完了🎉

流れはこう👇

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

ハンズオン：別名ボリューム復元テスト（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

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

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

ボリューム名が違う

docker volume ls で存在確認👀
Composeの external: true は「無ければ即エラー」なので事故りにくい (Docker Documentation)

起動はしたけどデータが空

目印データ（dr_marker）が入ってた“元バックアップ”を使ってる？🤔
バックアップ作成直後にテストするのが鉄板👍

権限/所有者でコケる（特に物理バックアップ系）

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 とチェック項目に最適化して書き換えるよ🙂✨

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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