バックアップは、あるだけでは足りない — 静かに止まり、小さすぎて不安になった一日

ダッシュボードが、実機とずれていた

前回、NGW に初めての Linux の土台を建てた。今日はその上で保守コンソールを回し始めた。ディスクやサービスの状態を一枚のダッシュボードで見せ、必要なら操作もできる管理ツールだ。

動かしてすぐ、妙なことに気づいた。同じ画面の中でディスクの数字が食い違っている。片方のパネルは半分ほど使用と言う。もう片方のライブ表示は2割ほどと言う。同じ一台のディスクだ。二つの値が並んでいた。

NGW保守コンソールのダッシュボード「システム」パネル。ホスト・OS・カーネル・ミドルウェア版数・稼働時間・負荷・メモリと、ディスク使用率を表示している

どちらかが古い。ライブのほうは実機を直に叩いている。正しいのはこちらだ。ならば、もう片方は古いスナップショットを表示している。その古い値は、あるファイルから来ていた。バックアップが最後に走ったときに書き残す状態ファイルだ。

ここで話が繋がる。状態ファイルが古いということは、バックアップ自体がしばらく走っていない。ダッシュボードのズレは表示バグではなかった。その裏で、もっと大事なものが止まっていた。

数字の裏で、バックアップが止まっていた

追うと、はっきりした。最後にバックアップが成功したのは、丸一日以上前。 この環境では DB のダンプを一日に何度か自動で取る。直近の分がひとつも走っていない。

原因は地味だった。バックアップの一式——スクリプトも、設定も、スケジュール表も——ファイルとしては在る。スクリプト自体も健全で、手で走らせれば端から端まで通る。そのスケジュールが、定期実行の仕組みに登録されていなかった。 予約表は机の上にある。誰も予約を入れていない。

止まった時刻に心当たりがあった。前回、この土台をゴールデンイメージから再構築している。その再構築の時刻と、バックアップが止まった時刻が、ぴたりと重なっていた。

レシピに無いものは、戻ってこない

ゴールデンイメージは、環境を何度でも同じ形に組み直せるレシピだ。前回はその利点をさんざん書いた。今日はその裏面を見た。

レシピに書いていないものは、再構築で戻ってこない。

バックアップのファイル一式はイメージに含まれていた。だから在ることは在った。だが、それを定期実行へ登録する一手間がレシピに書かれていない。再構築すれば、その一手間はすっぽ抜ける。ファイルは戻る。ファイルを動かす予約は戻らない。

厄介なのは、これが何のエラーも出さないことだ。バックアップが走らないことは、それ自体では悲鳴を上げない。ただ静かに走らないだけだ。今日気づけたのは、たまたまダッシュボードの数字がずれていて、その古さを不審に思ったからにすぎない。気づかなければ、次にデータを失うその日まで、誰も知らない。

登録し直し、その場で一度走らせた。予約が入り、最新のバックアップも確保できた。再構築の手順書に「予約を登録し直す」の一行を書き足した。今日の落とし穴はレシピの穴だ。塞ぐべきはレシピのほうだった。

今度は、小さすぎて不安になった

復旧したバックアップを見て、別の不安が湧いた。小さすぎるのである。

いちばんデータの重い団体の DB は、手元のツールで普通に書き出すと 6.5 GB ある。今回のバックアップは圧縮済みで 480 MB。13分の1だ。桁が違う。どこか欠けているのではないか。私はしばらくファイルサイズを二度見していた。

これは正常だった。理由は二段構えになっている。

ひとつ。SQL のダンプは中身がテキストで、同じような行が延々と続く。こういうデータは圧縮が非常によく効く。 10倍から20倍縮むのは普通のことだ。

ふたつ。そもそも書き出し方が違う。手元のツールの書き出しは1行1行が冗長で、それで 6.5 GB になっていた。今回使ったダンプは、多数の行をまとめて一文に詰める。圧縮する前の段階で、すでに 3.88 GB。 そこから圧縮して 480 MB。中身のデータ量は同じで、詰め方が上手いだけだった。

数字だけ見て「小さい＝欠けている」と早合点しなくてよかった。だが「たぶん大丈夫」で済ませてもいけない。バックアップは、いざというときに戻せなければ、あってもなくても同じだ。不安なら確かめればいい。

「ある」と「戻せる」は違う

圧縮ファイルを実際に開いて、中身が揃っているかを検証した。今日のいちばんのポイントはここだ。

圧縮ファイルとして壊れていないか。 展開が最後まで通るかを確かめる。
末尾に「ダンプ完了」の印があるか。 これが一番効く。生成が途中で失敗すると、圧縮ファイルとしては正常なのに中身が尻切れという最悪の状態になる。末尾の完了マーカーがあれば、途中で切れていないと保証できる。
テーブルの数が実 DB と合うか。 ダンプに含まれるテーブル定義は150。実 DB は177。差の27は何だ、と一瞬ひやりとした。正体はビューだった。177 ＝テーブル150 ＋ビュー27。ビューもきちんと収録されている。欠けも余分もゼロ。

このダンプは、表の中身だけでなくストアドルーチンもトリガもイベントも含む完全な形で取れていた。手元のツールの素の書き出しより網羅的だった。

このバックアップは、小さくても完全だった。 そして分かったことがある。「バックアップが在る」ことと「バックアップが戻せる」ことは別物だ。ファイルが在るだけでは安心できない。開いて、末尾まで揃っていると確かめて、初めてバックアップになる。

保守コンソールに、検証を持たせる

この「開いて確かめる」を毎回手でやるのは続かない。だから保守コンソールに検証を持たせた。ボタンひとつで、圧縮の整合性・テーブル数・中身の先頭を出し、健全かを一目で見せる。今日のアップグレードはこれだった。

最初の版には穴があった。先頭とテーブル数は見ているのに、末尾の完了マーカーを見ていない。 尻切れを捕まえる決定打はそこにある。圧縮が正常でも中身が途中で切れている、という一番たちの悪いケースを、先頭だけ見ていては見逃す。末尾マーカーの確認を足した。これでコンソールの「健全です」が、戻せることの保証に近づいた。

道具は状態を映すだけでは足りない。その状態が信じるに足るかまで、道具自身が確かめる。

AIとの協働作業での学び

今日の作業は、人と機械で気づきの種類がきれいに分かれていた。

止まっているバックアップに最初に気づいたのは、人の勘だった。 メトリクスが赤くなったわけではない。「再構築したあと、バックアップがなんだか動いていない感じがする」。数字になっていない違和感が入口だった。機械は「異常なし」としか言わない。走っていないことは、走っていないというエラーを出さない。何かがおかしいと感じるのは、まだ人の仕事だ。

それを確定させ、正確に突き止めたのは機械だった。 最後の成功時刻を拾い、予約が登録されていないことを確かめ、止まった時刻が再構築と重なることまで並べる。小さすぎる不安に対しても、機械はためらわなかった。圧縮を展開し、完了マーカーを探し、テーブル数を実 DB と突き合わせ、「テーブル150＋ビュー27で欠損ゼロ」と結論する。独立に検証した結果が、コンソールの検証結果と一文字違わず一致した。片方が片方の答え合わせになる。

いちばん効いた指摘はこれだ。

この検証は末尾の完了マーカーを見ていません。先頭とテーブル数が合っていても、途中で切れたダンプは検出できません。

人はつい、先頭とテーブル数が合っていれば安心する。尻切れは末尾にしか出ない。一番大事な保証が、一番見落とされやすい場所にある。

今日いちばん腹落ちしたのは、「ある」を「戻せる」に格上げするのが検証だということだった。バックアップは取っただけでは半分でしかない。開いて、末尾まで揃っていると確かめて、ようやく完成する。ゴールデンイメージも同じで、レシピに書いていない一手間は再構築で必ず消える。

……それにしても、480 MB を二度見していた自分のことは、しばらく忘れられそうにない。桁が違うと人はまず疑う。疑ったのは正しかったが、疑ったまま放っておいたら何も起きなかった。開けてみて、よかったのである。