第17章:バックアップの粒度:1日1回?変更時だけ?決め方📅
第15章・第16章で「バックアップは作れる&戻せる」状態になったので、今回は “どれくらいの頻度で / 何世代残して / どこに置くか” を決めます😎✨ ここを決めると、バックアップが「気分」じゃなくて「運用」になります💪🧰
0) 今日のゴール🎯
この章の終わりに、あなたのプロジェクト用に 超ミニのバックアップポリシー(5行くらい) が書けること📝✨ そして「毎日?変更時だけ?どっち?」って迷ったら、同じ手順で決められる ようになること🚦
1) “粒度”は3つのつまみ🎛️🎛️🎛️
バックアップの粒度=次の3つを決めることです👇
- 頻度:どれくらいの間隔で取る?(1日1回?1時間?変更時?)⏰
- 世代数:いくつ残す?(7個?30個?月次も?)🗃️
- 保存場所:どこに置く?(同じPCだけ?外付け?クラウド?)📦☁️
そして超重要ポイント:
バックアップは 「コンテナ」じゃなくて「データ(volume/bind)」が主役 です。コンテナを commit しても、volumeの中身は含まれないので別で守る必要があります⚠️ (Docker Documentation)
2) まず“失っていい量”を1分で決める(RPOの超入門)⏳🧠
難しい言葉っぽく聞こえるけど、言いたいことはこれだけ👇
-
**「最悪、何時間分のデータ消えても許せる?」**😇
- 例)「昨日の夜まで戻れればOK」→ 1日1回でだいたいOK
- 例)「30分分でも消えると痛い」→ もっと頻繁 or 仕組み強化
クラウドのマネージドDBでは「日次スナップショット+保持期間(例:7〜35日)」みたいな考え方が基本になってます。“どれくらい戻れる期間を用意するか” をまず決める、が王道です📌 (Microsoft Learn)
3) 頻度の決め方:この3パターンでOK👌📅
頻度はだいたい次の3つの組み合わせになります👇
A. 定期バックアップ(基本)🕒
- 1日1回:個人開発の標準になりやすい
- 1時間1回:運用寄り/データがよく増える
- 5分〜15分:かなり本気(やりすぎ注意😇)
決め方のコツ: 「失っていい量(例:24時間)」を、そのまま頻度にするのが一番ラクです👍
B. イベント時バックアップ(超おすすめ)🎬
次の前には “手動で1回” を足すと事故耐性が爆上がりします💥
- DBマイグレーション前🧱
- 大きいリリース前🚀
- バッチ処理・一括更新の前🧺
C. 変更があった時だけ(節約型)💡
- 「ほとんど更新されない」ならアリ
- ただし “更新されたかの検知” が難しいので、最初は A+B で始めるのが安全です🛡️
4) 世代数の決め方:まずは“3段ロケット”🚀🗃️
世代(何個残すか)は、最初はこれで十分です👇
✅ まずの型(迷ったらこれ)📌
- 日次:7世代(1週間分)
- 週次:4世代(1か月分)
- 月次:3〜6世代(四半期〜半年の保険)
これで「うっかり壊して、数日気づかない」系に強くなります😇
実用目線の補正(初心者向けチート)🎮
- バックアップが重い(容量デカい)→ 日次7だけ から開始でもOK
- 大事なデータ(課金・顧客・制作物)→ 週次+月次も足す
- 「壊れてるのに気づくのが遅い」タイプの開発 → 世代を厚く(14日とか)🧯
5) 保存場所の決め方:まずは3-2-1を“日本語で”理解する🧊☁️
有名な考え方に 3-2-1 ルール があります📦 要するに👇
- 3つコピーを持つ(元データ+バックアップ2つ)
- 2種類の場所/媒体に分ける(例:PC+外付け、PC+クラウド)
- 1つはオフサイト(家の外=クラウドや別PC/別拠点)☁️🚚
この定義そのものがシンプルで強いです💪 (backblaze.com)
さらに最近は、ランサム対策で 「書き換え不能(immutable)なコピーも持とう」 みたいに強化版(3-2-1-1-0)が語られることが多いです🔒 (Veeam Software) 超入門の範囲ではこう覚えればOK👇
最低1個は“勝手に消されにくい場所”に置く(例:クラウドの世代管理、書き込み制限、別アカウント保管)
6) 具体例:個人開発で使いやすい3つのポリシー案🧩✨
① ライト(まず形にする)🌱
- 頻度:1日1回
- 世代:7日分
- 保存:同じPC内+たまにクラウドへ手動コピー
👉 「最低限、戻せる」状態を作るスターター🎮
② スタンダード(おすすめ)⭐
- 頻度:毎日+大きい変更前に手動
- 世代:日次7+週次4
- 保存:PC内+クラウド(週1でもOK)
👉 だいたいの事故に勝てます😎
③ ちょい本気(小さく運用でも回す)🔥
- 頻度:1日1回+変更前
- 世代:日次14+週次8+月次6
- 保存:外付け or NAS+クラウド(オフサイト)
👉 「気づくの遅れた」系にも耐える💪
7) そのまま貼れる:バックアップポリシー(超ミニ)📝✨
これを README.md に貼るだけでOKです👇(5行〜で良し!)
【バックアップ対象】DBのvolume / アップロードファイル / 重要設定
【頻度】毎日 02:00 + マイグレーション前に手動1回
【世代】日次14、週次8、月次6
【保存場所】PC内(即復旧用)+クラウド(オフサイト)
【復元テスト】月1でリストアして起動確認(10分で)
※ 「volumeをtarで固める」やり方自体は公式にも例があります(--volumes-from で一時コンテナ作って tar)🧳 (Docker Documentation)
8) 演習(10分)⏱️🧠
演習1:RPOを決める📝
次を1行で書く👇
- 「最悪、◯時間分消えても許せる」
- 「気づくまで最大◯日かかりそう」😇
演習2:あなたの“最初のポリシー”を書く📌
上のテンプレをコピペして、数字だけ決める(7でも14でもOK)✨
演習3:イベント時バックアップのタイミングを決める🎬
あなたの開発で「怖い操作」を3つ書く👇
- 例)マイグレーション / 一括更新 / リリース前
9) よくある事故😱➡️回避策🛡️
- 同じPCだけに置いてた → PC故障で一緒に死亡☠️ → オフサイト1個は必須☁️
- 世代が少なすぎて“壊れる前”に戻れない → 日次7でもいいから持つ🗓️
- バックアップ取ったのに戻せない → “復元テスト”が本体(次章以降にも繋がる)🎭
- コンテナを保存したから安心と思った → volumeデータは別物です⚠️ (Docker Documentation)
10) Copilot / Codex に頼むとこ(安全運用)🤖🛡️
おすすめの使い方👇
-
ポリシー案を作らせる
- 「このプロジェクト(DB・uploadsあり)のバックアップ頻度と世代案を3パターン出して。理由も」
-
リスクの洗い出し
- 「この運用だと起こりそうな事故ベスト5と対策」
-
注意:バックアップ先・鍵・パスワードなどの秘密は貼らない🔒(ここは徹底!)
次の第18章は、このポリシーを “本当に戻るか?”を遊びながら検証する(DRごっこ) に進みます🎭🔥 第17章で決めた数字が、そのまま「復元テストのしやすさ」に効いてきますよ😉