個人開発の記録です。7月が終わり、電車アプリは「待ち」の期間に入りました。その合間にやった配管仕事——バックアップ体制の整備——で、ゾッとする発見がありました。今回はその話です。

まず結論

ふと聞いた一つの質問がきっかけで調べたら、バックアップが5日間、静かに死んでいました。誰にも気づかれずに。しかも過去に取ったバックアップの一部は、消えていました。

それでも実害はゼロでした。本体のデータが無傷だったからです。でも、もし気づくのが「本体が壊れた日」だったら——バックアップは死んでいて、過去の分は消えている。一番必要な日に、一番役に立たないところでした。

今週の学びを先に言うと、こうなります。

バックアップの本体は「取ること」ではない。
「動き続けていると、確認できること」のほうだ。

きっかけは、何気ない質問だった

発端は、ストレージを整理していて浮かんだ素朴な疑問でした。「そういえば、日々貯まっているデータのバックアップって、ちゃんと要る/要らないを考えたっけ?」

調べてもらうと、バックアップの仕組み自体は、以前ちゃんと作ってありました。ところが——その常駐ジョブが、いつの間にか登録から消えていたのです。最後に動いたのは5日前。原因は、調べても特定できませんでした(macOSの更新やログイン周りで、常駐の状態が変わることがあるようです)。

これは、このブログで何度も書いてきた「サイレント故障」の最悪版です。アプリの計算が狂えば画面の数字がおかしくなり、いつか気づけます。でもバックアップは、止まっても日常は1ミリも変わりません。気づく機会が来るのは、本体が壊れた日——つまり手遅れの日だけ。静かに死ぬものの中で、バックアップは一番たちが悪い。

学び①:原因究明より、検知

「なぜジョブが消えたのか」を深追いしたくなりました。でも、今回は追わないと決めました。事後からは追いにくいうえ、仮に原因が分かっても、別の原因で同じことがまた起きる可能性は消えないからです。

代わりに立てた方針はこうです。「なぜ消えたか」より「消えたら2日以内に必ず気づける」。原因不明は「不明」と正直に記録した上で、見張り番を立てる。再発防止として、原因究明より検知のほうが強い保証になる——これは病院SEの障害対応の感覚とも一致していて、腑に落ちました。

学び②:狼少年にしない警報の作り方

では、どんな見張り番にするか。ここが今回いちばん設計として面白かった部分です。単純に「バックアップが1回失敗したら警報」にすると、困ったことが起きます。私の環境では、バックアップ元のマシンが夜スリープしていることがあり、その一晩のために鳴る警報は、すぐ”狼少年”になるのです。誤報が続く警報を、人は読まなくなります。

だから警報を二層にしました。

  • 相手が寝ているだけなら、黙ってスキップ(警報なし)
  • ただし「最後に成功した日」からの経過を見て、2日間成功がなければ必ず警報

一行にすると——「一時の沈黙は許し、続く沈黙は許さない」。スキップは”成功”を更新しないので、本当に止まり続ければ2日で必ず鳴ります。誤報で信頼を失わず、実害は逃さない。警報は感度を上げるほど良いのではなく、読まれ続けることが第一条件なのだと学びました。

学び③:「コピーした」と「同じものがある」は、別の主張

体制の作り直しでは、まず現存データを新しい保管先へ退避しました。ここでも一つ、規律を守りました。コピーが終わったあと、2つの独立した方法(照合方式の違う検証を2種類)で「元と先が同じであること」を確かめるようにしたのです。

なぜ2つか。「コピーした」は操作の報告にすぎず、「同じものが向こうにある」は検証して初めて言える主張だからです。1つの検証方法には、その方法自身の見落としがあり得る。別の原理の検証を重ねると、片方の弱点をもう片方が補います。成績表のときに置いた「見張り番」と、同じ思想でした。

学び④:完了条件は「わざと止めて、鳴ること」

そして最後の仕上げ。この体制の完了条件を、「バックアップが動くこと」ではなく「わざと止めたとき、警報が実際に鳴ること」にしました。

見張り番を作っても、その見張り番が動いている保証はどこにもありません(今回死んでいたのが、まさに”以前作った仕組み”でした)。だから、故意に止めて、警報が届くのをこの目で見て、それから正常に戻す。「正しく壊れるか」を確かめて、初めて完成——接続断のときに学んだ型を、そのまま使いました。

おわりに ── 消えない保証が、証拠の下に入った

これで、収集・判定・成績表・週次レポートに加えて、バックアップと監視までが「私が見ていなくても働き、止まったら騒ぐ」仲間に入りました。前回書いた「証拠の鎖」——凍結した基準で測り続けた実績——は後から作れない資産ですが、今回の仕事はその資産が消えないことの保証です。鎖の下に、コンクリートの土台が入った格好です。

振り返ると、今回の一件は「良い質問が資産を救った」話でした。何気ない「これ、バックアップ要らないんだっけ?」の一言がなければ、死んだバックアップは本体が壊れる日まで死んだままだったはずです。動いているはずのものにこそ、たまに「本当に動いてる?」と聞いてみる。今週いちばんの教訓です。

週明けには、初めての自動週次レポートが届く予定です。数字が出たら、また書きます。


個人開発 / バックアップ / 監視設計 / サイレント故障

このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。