バックアップは安全網であって、マイグレーション戦略ではない

あなたのチームは先ほど、orders_archive テーブルを削除するデータベースマイグレーションを実行したとします。データは新しいテーブルに移行済みで、すべてきれいに見えていました。しかし、誰も覚えていない古いシステムがまだそのテーブルを参照していました。テーブルは消え、データも消え、再作成するための新しいマイグレーションには復元するデータが何もありません。

あるいは、price カラムを INTEGER から DECIMAL に変更したところ、1時間ごとに動作するバッチジョブがまだ整数をそのカラムに書き込んでいて、レコードを静かに破損させているかもしれません。

こうした瞬間、次のような本能的な反応は理解できます。「バックアップがある。マイグレーション前の状態にデータベースをリストアしよう。」

それはもっともに聞こえます。しかし、その結果は元の問題よりも悪化することがよくあります。

バックアップの本来の目的

バックアップは壊滅的なシナリオのために存在します。サーバールームの火災、ストレージアレイの障害、ディスクの破損、管理者による重要なテーブルの誤削除。そうした状況では、バックアップからのリストアが正しい判断です。他に選択肢はなく、リストアしない場合の代償は完全なデータ損失です。

しかし、マイグレーションの失敗は壊滅的な事態ではありません。それは日常的な運用イベントです。それを災害のように扱うと、新たな問題を生み出します。

バックアップベースのロールバックにおける2つの問題

データ損失

バックアップは特定の時点におけるデータのスナップショットです。午前2時にバックアップを取得し、午前10時にマイグレーションが失敗した場合、本番データベースにのみ存在する8時間分のユーザーアクティビティが発生します。注文、プロフィール更新、サポートチケット作成、設定変更などです。

午前2時のバックアップをリストアすると、それらすべてのデータが消失します。別のソースがない限り、それを取り戻す方法はありません。このギャップは、バックアップとリストアの間の時間が長くなるほど大きくなります。ポイントインタイムリカバリを使用して午前9時59分の状態にリストアしても、その最後の1分間に発生したものは失われます。

ダウンタイム

データベースのリストアは瞬時には完了しません。数百ギガバイト規模のデータベースの場合、リストアに数時間かかることがあります。その間、アプリケーションは通常通りトラフィックを処理できません。データは不整合で、部分的にロードされているか、リストアプロセスによってロックされています。

これと比較して、ロールフォワードアプローチでは、数分で完了する新しいマイグレーションを実行します。あるいは、アプリケーションを停止せずにデータを調整する補償スクリプトを実行します。バックアップベースのロールバックは、チームにデータ損失か長時間のダウンタイムかの選択を強います。多くの場合、両方を招きます。

ポイントインタイムリカバリは軽減するが解決しない

一部のチームはポイントインタイムリカバリ（PITR）を使用してデータギャップを減らします。最後のフルバックアップにリストアする代わりに、マイグレーション実行の1分前など、特定のトランザクションログ位置にリストアします。

これは役立ちます。失うデータは少なくなります。しかし、それでも一部は失われます。マイグレーションの数秒前に完了したトランザクションは消えます。そして、リストア自体には依然として時間がかかります。PITRはフルバックアップリストアよりは優れていますが、クリーンなロールバックメカニズムではありません。

リカバリ階層におけるバックアップの位置づけ

バックアップはデータベースリカバリにおいて明確な役割を持っています。それは最後の手段です。他のすべてが失敗し、データ損失とダウンタイムを受け入れても代替手段よりはましな場合の安全網です。

成熟したチームでは、バックアップは定期的に取得され、定期的にテストされます。しかし、マイグレーションがうまくいかなかった場合、チームはまずバックアップに手を伸ばしません。彼らは階層に従って作業します：

以下のフローチャートはこの判断プロセスをまとめたものです：

flowchart TD A[Migration fails] --> B{Can you roll-forward?} B -- Yes --> C[Write new migration or compensating script] B -- No --> D{Is a down migration safe?} D -- Yes --> E[Run down migration to revert] D -- No --> F[Consider backup restore] F --> G[⚠️ Data loss and downtime expected]
  1. ロールフォワード: 変更を元に戻すか、欠落している部分を追加する新しいマイグレーションを作成します。
  2. 補償スクリプト: 完全なマイグレーションなしでデータを調整するスクリプトを実行します。
  3. バックアップリストア: データ損失とダウンタイムのトレードオフを評価した後にのみ実行します。

バックアップに手を伸ばす前の実践的チェックリスト

バックアップからリストアする前に、次の質問を自問してください：

  • 削除されたテーブルやカラムを追加し直すマイグレーションを作成できますか？
  • ログや他のソースから失われたデータを再構築する補償スクリプトを実行できますか？
  • 最後のバックアップからリストアした場合、どれだけのデータを失いますか？
  • リストアにはどのくらいの時間がかかり、ビジネスはそのダウンタイムを受け入れられますか？
  • データを修正している間、アプリケーションを部分的に稼働させ続ける方法はありますか？

最初の2つの質問に対する答えが「はい」の場合、バックアップリストアは必要ありません。最後の3つの質問に対する答えが「受け入れられない」場合、別の方法を見つける必要があります。

まとめ

バックアップは災害時の安全網であり、マイグレーションのロールバック戦略ではありません。マイグレーションが失敗した場合、まずロールフォワードまたは補償スクリプトから始めてください。それらの選択肢が尽き、データ損失とダウンタイムのコストを受け入れた場合にのみ、バックアップに手を伸ばしてください。バックアップをデフォルトのロールバック計画として扱うチームは、本番データを失い、眠れぬ夜を過ごすことになります。