Skip to main content

第17章：バックアップの粒度：1日1回？変更時だけ？決め方📅

第15章・第16章で「バックアップは作れる＆戻せる」状態になったので、今回は “どれくらいの頻度で / 何世代残して / どこに置くか” を決めます😎✨ ここを決めると、バックアップが「気分」じゃなくて「運用」になります💪🧰

0) 今日のゴール🎯​

この章の終わりに、あなたのプロジェクト用に 超ミニのバックアップポリシー（5行くらい） が書けること📝✨ そして「毎日？変更時だけ？どっち？」って迷ったら、同じ手順で決められる ようになること🚦

1) “粒度”は3つのつまみ🎛️🎛️🎛️​

バックアップの粒度＝次の3つを決めることです👇

  1. 頻度：どれくらいの間隔で取る？（1日1回？1時間？変更時？）⏰
  2. 世代数：いくつ残す？（7個？30個？月次も？）🗃️
  3. 保存場所：どこに置く？（同じ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章で決めた数字が、そのまま「復元テストのしやすさ」に効いてきますよ😉