バックアップ監視でID重複を見落とす理由:別リソースを正常と判定した事例

パステル系を描いたアイキャッチ画像

バックアップ監視で成功フラグが1、時刻も新しく、サイズももっともらしい。それでも安心できない場面があります。複数のコンテナや仮想マシンを扱い、「番号が同じなら同じ対象だろう」と考えたくなる運用者にとって、これは見過ごしにくい落とし穴です。

今回、監視はhomelab_chemy_backup_probe_success=1を返していました。最新時刻は1784228483、サイズは34,359,739,141 bytesです。数値だけを見る限り、監視は正常に機能しているように見えます。

しかし、必要だった監視対象はコンテナ種別のct/1000でした。監視が見ていたのは、仮想マシン種別のvm/1000/2026-07-16T19:01:23Zです。同じ1000でも、対象は同じではありません。

目次

数値IDは名札ではなく、住所の一部です

数値IDだけで対象を識別するのは、部屋番号だけを読んで郵便物を届けるようなものです。建物名や階が欠けていれば、同じ番号の別室へ届く可能性があります。

バックアップの監視でも同様です。IDは便利な索引ですが、対象の身元そのものではありません。少なくとも、次の組で照合する必要があります。

storage + resource type + ID

ここでいうstorageはバックアップ保存先、resource typeはコンテナか仮想マシンかといった種別です。この三つがそろって初めて、監視対象を十分に区別できます。

本来の最新スナップショットはbackup/ct/1000/2026-07-16T12:00:00Zで、サイズは55,283,988,650 bytesでした。監視はより新しい別対象を拾っていたため、本来のコンテナ側が古くなっても、正常を返し得る状態になっていました。これはバックアップ監視におけるfalse healthy、つまり「健康に見える誤判定」です。

まず、監視値を一次データと順に突き合わせます

確認項目 見ること 今回の結果
数値ID 意図した番号か どちらも1000で、一見すると一致
種別 コンテナか仮想マシンか 必要なのはct、監視値はvm
保存先 意図したバックアップ保存先か 保存先・種別・IDの組で判定すべきだった
時刻とサイズ 実データと値が一致するか 監視値は別種別のvm/1000と完全一致

時刻とサイズが正しいことは、対象が正しいことの証明にはなりません。成功フラグ、最新時刻、サイズのすべてが整っていても、別種別の同一番号を指していれば、その成功は誤配達です。

監視値そのものの鮮度も別途確認すべきです。値が古いまま残っていないかという観点は、既出の値ではなく「値と鮮度の組」を監視するで整理しています。ただし、値が新鮮でも対象が違えば意味は変わります。鮮度の確認とidentityの確認は、代替関係ではなく両方必要です。

実装とテストが一緒に間違うことがある

図解: 実装とテストが一緒に間違う(数値IDで絞る / backup/vm/1000/ / 自己テスト / 実装もテストも通ります / 完全な識別子で照合 / コンテナ側が選ばれる)
図解: 実装とテストが一緒に間違う(AI生成)

原因は、一覧を数値IDで絞った後、解析側がbackup/vm/1000/を正解として固定していたことでした。さらに自己テストも、その誤った種別を正解データにしていました。

この状態では、実装もテストも通ります。しかし、二つが同じ誤った前提を共有しているだけです。テストが緑であることは重要ですが、テスト対象の選び方まで自動的に正しくしてくれるわけではありません。

修正では、保存先・種別・IDを合わせた完全な識別子で照合するようにしました。そしてct/1000と、より新しいvm/1000を同じテストデータに置き、コンテナ側が選ばれることを確認しています。回帰テストは4件PASSしました。

ここでの要点は「新しい方を選ぶ」ことではありません。正しい完全identityに一致する方を選べることです。正常な対象だけをテストデータに置くと、番号の重複や種別の混在による誤選択は検出できません。

修正後に変わった値と、残る判断

修正後の監視値はtimestamp 1784203200、size 55,283,988,650Bとなり、意図したct/1000の実値と完全一致しました。鮮度の実年齢は約16.7時間で、設定した36時間の閾値内です。

これは「時刻が新しい」ことだけではなく、「意図したコンテナの時刻とサイズである」ことまで確認できた状態です。一方で、36時間という閾値があらゆる環境に適切だとは限りません。バックアップ頻度、復旧に必要な時点、保存先の運用に合わせて決める必要があります。

自動化の完了条件も、処理が成功したかだけでは不十分です。少なくとも監視やバックアップでは、「意図した対象の実データと一致したか」までを完了条件に含めると、成功を受け取る判断がかなり堅くなります。

運用に入れる三つの確認

  • IDのほかに、種別と名前空間または保存先を照合キーに持たせる
  • 監視値の時刻・サイズを、意図した対象の実データと突き合わせる
  • 同じIDを持つ別種別の対象をテストに混ぜ、正しい対象を選べるか確認する

数値IDだけは対象の同一性を証明しません。成功値を信じる前に、対象を完全なidentityで照合する。この一手間が、もっともらしい正常判定を、実際に信頼できる完了条件へ変えます。

この検証を回している環境

この検証は、自宅の常設ラボ(使い捨てVM/LXCを回す母艦+GPU+VLAN分離ネットワーク)で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。

ラボ構成のまとめを見る →
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次