配布資料 44事例 #04: スキーマ比較コマンドの誤用で開発 DB が全消去された

「差分を比較するだけ」だと思っていました。実際は破壊的でした。 しかも同じ日に、バックアップも死んでいました。

何が起きたか

Prisma の migrate diff --shadow-database-url に、実際に使っている開発 DB の接続文字列を渡してしまいました。

開発 DB が shadow database として破壊的にリセットされます。全テーブルを DROP してマイグレーションを replay する挙動です。全データが消えました。

さらに同じ日、本番 DB のフルバックアップが約19日間サイレント失敗していたことも発覚しました。 このまま失敗が続けば、まもなく特定時点への復元ができなくなる状態でした。

「開発 DB の全消去」と「本番バックアップの不在」が同日に重なりました。 これが、環境を問わない事前バックアップ鉄則の直接の動機になっています。

なぜ起きたのか

表面的には、--shadow-database-url に実 DB を指定した操作ミスです。

構造は3つです。 ①「差分を比較するだけ」に見えるコマンドが「指定 DB を破壊的にリセットする」仕様であることの理解不足 ②DB に触れる前のバックアップ習慣がなかったこと ③バックアップの側に「成功したつもりのサイレント失敗」を検知する監視がなかったこと

そこから生まれたルール

「Prisma で DB に触れる直前（migrate deploy / migrate dev / db push / migrate diff）に、環境を問わず必ず手動バックアップを取得する」。環境別のコマンドまで手順書に明記しました。

「--shadow-database-url に実 DB を指定しない。使うなら専用の空 DB のみ」

事故当日のうちに規約にしました。

どう機械に守らせたか

ここは運用ルールが主体になっています。 デプロイスクリプトへの自動バックアップ組込は構成が複雑なため見送り、手順の明文化とセッション開始時の規律注入で対応しました。

バックアップの側は、サイレント失敗の再発防止として鮮度監視スクリプトと失敗時のメール通知を本番に配備しました。

持ち帰るなら

①ORM やマイグレーションツールの「比較・同期系コマンド」は破壊的仕様を疑ってください。そして事故ったコマンドは規約で名指しして禁止します

②バックアップは「取っているはず」が一番危ないです。取れているかを監視する仕組み——鮮度チェックと通知——までがバックアップです。