CMSのバックアップ｜壊れたときに戻すのは、ファイルではなく1件のレコードだった

ある朝、検索順位を定点観測していたら、トップページのJSON-LD構造化データが消えていることに気づいた。
検索結果のリッチリザルトにも、AIが参照する情報にも、何も出てこない。
コンテナの構造化データを扱うコードを何度読み返しても、怪しい箇所は見当たらなかった。
結局、原因がコードのバグではなく、データそのものが汚れていたのだと分かるまでに半日かかった。

疑うべきはコードではなく、1件のレコードだった

設定を1つずつ辿っていくと、トップページに「構造化データを出力しない」という管理フラグが立っていることに気づいた。
自分でそのフラグを立てた記憶はない。
更新ログを確認すると、管理画面のセッションを経由しない、外部からの直接のPOSTリクエストによってそのフラグが書き換えられていた。
更新者の記録も、人のユーザーIDではなくシステム扱いになっていた。
コードのバグではなく、想定していない経路からデータが汚染されていた、というのが実態だった。

バックアップから丸ごと戻す、という手は取らなかった

一番手っ取り早いのは、前日分のフルバックアップから丸ごと復元することだったと思う。
けれどその間には、他のページの更新や新しい投稿も何件か入っている。
1件のフラグを直すためだけに、それらをまとめて巻き戻すわけにはいかない。
結局やったのは、汚染されたレコードだけをピンポイントで特定して、そこだけを直す作業だった。
対象は投稿用のテーブルと、表示用に反映されるテーブルの両方にまたがっていて、片方だけ直すと今度は2つの件数がずれてしまう。

物理的に消さず、無効化して残す

直し方にも、コンテナ側の設計思想が関わってくる。
このCMSはレコードを物理的にDELETEでは消さず、ステータス値を変えて無効化する作りを、基盤の段階から徹底している。
今回もその流儀にならい、汚染された設定行をDELETEするのではなく、無効を示すステータスへ変更する形で処理した。
もし物理削除する設計だったら、いつ・どの値で・どこから汚れたのかという痕跡ごと消えていたはずだ。
直したあとは、公開中の全ページを対象に、構造化データの欠落と未解決の参照がゼロであることを1件ずつ機械的に確認した。

守りたいのはファイルではなく、変更の履歴だった

この一件のあと、バックアップに対する考え方が変わった。
毎日フルバックアップさえ取っておけば安心、というものではない。
大事なのは、いつ・どのレコードが・どう変わったかを、あとから追える状態を保っておくことだと思う。
うちでは投稿や固定ページの変更履歴を残す仕組みをコアの標準機能として持たせていて、今回もその記録に助けられた。
フルバックアップは最後の保険として残しつつ、普段の事故は履歴を見て1件ずつ直す、という役割分担に落ち着いている。

月次の点検に、この確認を1つ加えた

原因の特定に半日かかったのは、そもそも「管理画面を経由しない書き換え」を疑う発想が最初になかったからだ。
構造化データが正しく出ているかどうかは、これまでも定期的に確認していたが、値そのものだけを見ていて、誰が・どの経路で最後に更新したかは見ていなかった。
今は主要ページの構造化データを月次で確認する際に、更新者の記録がシステム扱いになっていないか、管理画面のセッションを経由しない更新が入っていないかも、あわせて点検する項目に加えている。
事故そのものを完全に防ぐのは難しくても、次に同じことが起きたときに、原因の特定にかかる時間は半日よりずっと短くできるはずだと思う。

バックアップと復旧の考え方は、DB・バックアップ／メンテナンスの機能ページでも紹介している。