技術ログ

個人開発者のバックアップ戦略 (3年分のコードを守る)

公開: 2026-05-19 · 著者: Sasaki Ryuji

個人開発のコードと環境を失う日は突然来る、その備えを最初から作る

あなたが個人開発で複数のプロジェクトを抱えているなら、PCクラッシュ時の備えは最重要事項です。コードは GitHub に push しているから安心、と思っているかもしれませんが、ローカル設定、.env ファイル、node_modules の一部の状態、ドキュメント類は GitHub に上がっていません。私はある時点でGoogle Drive一本化の自動バックアップ運用に切り替え、3年分のコードと環境を守れる体制を作りました。実装と運用ノウハウを共有します。

OneDrive 併用時代の問題

初期の私のバックアップは OneDrive 自動同期に任せていました。OneDrive をデスクトップに紐付け、デスクトップにプロジェクトフォルダを置けば自動で同期される、という仕組みです。シンプルで便利でしたが、いくつか問題が発生しました。

第一に、node_modules が毎回同期対象に含まれ、容量が無駄に膨らみました。1プロジェクトあたり 500MB以上の node_modules がクラウドにアップされ続けるのは非効率です。第二に、同期競合が頻発しました。ローカルでファイルを書いている最中に同期が走ると「競合ファイル」が複数生成され、どれが最新か分からなくなる現象です。第三に、有料プランの容量を圧迫しました。

Google Drive 一本化への切替

2026年5月、バックアップ運用を Google Drive 一本化に切り替えました。OneDrive 自動同期を停止し、自前のバックアップスクリプトで毎日03:00に Google Drive にアップロードする形に変更しました。これにより、同期競合がゼロになり、容量も管理しやすくなりました。

新しい構成は以下の通りです。第一に、毎日03:00に Windowsタスクが backup-all.mjs を実行。第二に、対象フォルダを tar.gz で圧縮、node_modules/dist/playwright-profile/local-cache は除外。第三に、生成したアーカイブを Google Drive (Claude-PC-Backups フォルダ) にアップ。第四に、アップ成功後、ローカルのアーカイブを削除。第五に、Google Drive 側で FIFO 30件を維持 (古いものは自動削除)。

除外設定の落とし穴 — local-cache を含めない

バックアップ対象の除外設定で、最初に踏み抜いた罠が「local-cache」フォルダの再帰圧縮でした。バックアップシステム自身が生成する圧縮ファイルが C:/AI_WORK/backup-system/local-cache/ に一時保存される構造だったのですが、バックアップ対象 C:/AI_WORK 全体を圧縮しに行くと、自分自身が生成した圧縮ファイルも含めて再圧縮しようとして、アーカイブが無限に膨らむバグになっていました。

修正は単純で、除外リストに local-cache を明示的に加えるだけです。tar --exclude='local-cache' --exclude='node_modules' --exclude='dist' --exclude='playwright-profile' のような形で除外。これでアーカイブサイズが約 8GB から約 600MB まで圧縮され、Google Drive アップロード時間も大幅短縮されました。

復元手順を定期的にテストする

バックアップで最も危険なのは「バックアップを取っていたが、復元できないことが本番障害時に判明する」パターンです。私は3ヶ月に1度、テスト用の仮想マシンで「バックアップから完全に環境復元できるか」をテストしています。手順は概ね以下です。

# 1. Google Drive から最新アーカイブをダウンロード
gdrive download --id [FILE_ID]

# 2. 解凍
tar xzf ai_work_2026-05-18.tar.gz -C C:/AI_WORK_RESTORE

# 3. 各プロジェクトで npm install
cd C:/AI_WORK_RESTORE/ai-pick && npm install

# 4. .env を別途復元 (.env はバックアップ対象外、別途暗号化保管)
cp /path/to/encrypted/.env.gpg C:/AI_WORK_RESTORE/ai-pick/.env
gpg --decrypt .env.gpg > .env

# 5. 動作確認
npm run dev

3ヶ月に1回のテストで、何度か「あれ、復元が想定より複雑」というケースを発見しました。.env の暗号化保管を別ルートにしたり、npm install の競合パッケージを記録したり、復元手順をドキュメント化し続けることが大事です。

個人開発の継続性はバックアップで決まる

個人開発で1年以上同じプロジェクトを続けると、コードだけでなく「環境設定」「ドキュメント」「ノウハウ」が積み上がります。これらが失われると、復旧に数週間-数ヶ月かかります。Google Drive 一本化の自動バックアップは、月コストゼロ (Google Drive 無料15GB枠で十分) で、復元の安心感を大きく高めます。

個人開発者として、バックアップは「面倒だがやるべきこと」ではなく「事業継続性の保証」と捉えるべきです。私の3年分のコードは、PC が突然壊れても24時間以内に別マシンで動かせる状態になっています。

運用基盤の作り方は技術ログ、リスク管理の判断はビジネスカテゴリに追記しています。