とあるシステムでの話ですが、DBのとあるテーブル（以降、Aテーブルと呼ぶ）において、特定カラム（以降、Bカラムと呼ぶ）の全データを、想定外に書き換えてしまうトラブルが発生しました。
詳細までを書くことは出来ませんが、直接の原因は管理画面の誤操作です。
トラブル解決編
管理画面の誤操作が発覚後、まずはデータ復旧となりました。
最新の日次バックアップから復元DBを作成する
数時間前に取得されていた最新の日次バックアップを使い、日次バックアップから復元DBを新規作成しました。 これにより、データ書き換えのトラブルが発生する前のデータベースを再現します。
復元DBから現行DBへ、AテーブルBカラムのデータを流し込む
復元DBから、AテーブルのBカラムを抽出し、現行DBへ流し込むという作戦です。 これにより、データ書き換えのトラブルが発生する前の、Bカラムデータで上書きします。
復元DBからは、主キー (ID) と対象カラムを抽出したCSV形式のデータを作りました。 そいつをプログラムを使って読み込ませ、現行と差分があればUPDATE SQLを発行し、AテーブルのBカラムを復旧させました。
Bカラムは管理画面からしか更新できないデータだったのですが、日次バックアップ取得時点以降の管理画面操作で、当該カラムを更新する他の作業はなかった事が分かり、復旧完了となりました。 （実際は他にも色々と調査したり、残作業はあったのですが。書けないので割愛します。）
学び編
学びや改善点だらけの気はしますが。
- (フールプループ) 管理画面の誤操作とは言え、データ検索画面とデータ更新画面の取り違えが原因だったため、少なからずUIには課題がある。
- (作業体制) 本番環境の管理画面は超重要なので、安易なソロオペ事故の元。可能ならペアオペ体制を組みたい。
その他にも色々と課題が挙がり、それはそれで改善やふりかえりの対象となりました。 その中で、復旧作業において今後悔しているのは、PITRから復旧しなかったことです。
Cloud SQLのPITR (point-in-time recovery) は簡単に使える
Cloud SQLのPITRは、デフォルトで有効パターンも多く、割と気軽に使えます。 また、無効だったとしても、「インスタンスの編集 (Edit) => データ保護 (Data Protection)」から有効に出来ます。 (ただし、有効無効の切り替え時にデータベースが再起動されます)
PITRからトラブル直前のポイントを指定してDBクローンを作成すれば、より直近のAテーブルBカラムからデータ復旧できるというわけです。
Cloud SQLのPITRは、Google Cloud Techの動画が、英語ですが簡潔に解説されています。 5分半の短時間動画で説明できるくらいに、簡単に扱えます。
あとがき
Cloud SQLのPITRを有効にしているならば、やらかし及びトラブルからの復旧はPITRがオススメです。 私が管理画面を誤操作したわけではないのですが、当時の私は慌てており、PITRを有効にしていたにも関わらず失念しておりました。
PITRを胸に刻むのと、あとは緊急トラブル時に慌てないよう、データ復旧マニュアルを作るべき。
