Gadget 20:ロールバック手順
更新や変更に失敗したとき、戻るための確実な手順
ロールバック手順
「戻す」が確実にできるための手順です。
目的
- 失敗しても必ず前の状態へ戻せる
- 戻し方を迷わず、検証してから更新を始められる
前提条件
- 更新前のバックアップ(07-backup-restore)
- 直前の状態(タグ or commit)を知っている(06-updates-strategy)
手順
1. 更新前に「戻る地点」を作る
cd cloudflare-os
git tag pre-YYYYMMDD # 更新前タグ
git push origin pre-YYYYMMDD # (任意)リモートにも保存
tar czf ../cfos-backup-$(date +%F).tgz .wrangler .dev.vars2. 失敗したら戻す
pkill -f run-local # プロセス停止
git checkout pre-YYYYMMDD # 前のタグ/コミットへ
pnpm install --frozen-lockfile
tar xzf ../cfos-backup-YYYY-MM-DD.tgz # データ復元(.wrangler, .dev.vars)
pnpm run-local &3. 戻したことを検証
4. 原因を記録する
ロールバックを使ったら「何が起きたか」を 1 行残す(19)。
よくある失敗
| 症状 | 原因 | 対処 |
|---|---|---|
| 戻したのに同じ症状 | データ(.wrangler)が新しすぎる |
更新直前のバックアップ tarball に合わせて戻す |
git checkout に失敗 |
dirty な変更が残っている | git status を確認、必要なら git stash |
| 戻り先が曖昧 | タグ無し | 更新前に必ずタグ/コミットを打つ |
| 連携が死んだまま | .dev.vars を元に戻せてない |
バックアップに含めて復元 |
Tip戻るなら「コード+データ」セット
コードだけ戻しても .wrangler が新しければ壊れたデータで起動します。 タグとバックアップ tarball をセットで持つことがコツです。
確認
次に読む
- 更新戦略 → 06-updates-strategy
- バックアップ → 07-backup-restore
- 障害対応 → 19-incident-playbook