バックアップの「見張り役」を外に置く【商店街振興組合IT再整備・番外編】
NAMIKI ASSOCIATESはじめに
過去の記事（NASのバックアップ停止と、3か所保管への見直し）では、「正常」と表示されていたNASの裏でバックアップが止まっていたことと、その後に整えた保管体制について書きました。
現在、商店街振興組合のNASは、倉庫にあったFujitsu製PCから毎晩2時にGoogle DriveとUSB-HDDへ複製しています。このPCはHDDをSSDに換装し、Linux Mintを入れてバックアップサーバーとして再利用したものです。倉庫に眠っていたPCが、今も現役で組合のデータを守っています。バックアップに失敗したときは、担当者へメールを送る設定です。
ただし、この仕組みには見落としうる穴があります。失敗メールを送るのは、バックアップを動かすPC自身です。PCの電源が落ちている、自動実行が動いていない、メール送信に失敗している。こうした場合は、失敗の通知も届きません。「何も届かない」だけでは、処理が成功したのか、PCが報告できない状態なのかを区別できません。
そこで、毎日のバックアップを外から確認する役を、社外のサーバーに置くことにしました。
見張り役を社外に置く
見張り役には、以前から契約していたメモリ1GBの小さなVPSを使いました。
バックアップサーバーのFujitsu PCは、処理を始めたときに「開始」、終わったときに「結果（Drive・USBそれぞれの成否）」をVPSへ送ります。VPSは毎朝6時以降、1時間ごとにその日の報告を確認します。
| その日の報告 | 判定 |
|---|---|
| 「結果」があり、Drive・USBとも成功 | 正常。通知しない |
| 「結果」があり、どちらかが失敗 | 異常。失敗した保管先を通知 |
| 「開始」だけで「結果」がない | 異常。処理が終わっていない |
| 何も届いていない | 異常。PCの停止、自動実行の不調、通信の不通など |
大切なのは、最後の行です。「報告が来ない」こと自体を異常として扱うため、PCが何も知らせられない状態でも気づけます。一方、報告の送信に失敗しても、バックアップ本体の処理や結果には影響しないようにしています。監視のためにバックアップを止めては本末転倒だからです。
異常はスマートフォンへのプッシュ通知（ntfy）で受け取り、正常な日は通知しません。見張り役自身が動いていることは、毎朝の定期報告で確認しています。
組織のネットワークはつながない
倉庫のバックアップ用PCからVPSへ報告するには、両者の間に通信経路が必要です。バックアップ用PCも当方の機器もTailscaleを使っていますが、組合と当方は別組織なので、Tailscaleのネットワークも別々です。
二つのネットワークを一つにまとめる方法もあります。しかし、それでは組合の機器から当方の社内機器へ、当方の機器から組合の機器へと、今回の目的に必要のない経路まで広がるおそれがあります。
そこで、Tailscaleのノード共有を使い、VPS 1台だけを組合側へ共有しました。さらに、VPSのある側のアクセス制御で、共有ノードからVPSのSSH（22番ポート）への通信だけを許可しています。
// 共有ノードからVPSのSSHだけを許可するルールの例
{
"src": ["autogroup:shared"],
"dst": ["<VPSのTailscaleアドレス>"],
"ip": ["tcp:22"]
}実際のポリシーでは、共有ノード全般に広く許可が及ばないよう、共有対象と宛先を確認して設定しました。バックアップ用PCから当方の社内機器へ接続を試み、届かないことも確認しています。ネットワークは分けたまま、報告に必要な経路だけを通しています。
報告用の鍵に、できることを一つだけ
報告はSSHで送ります。倉庫のバックアップ用PCは深夜に無人で送信するため、秘密鍵にパスフレーズを付けられません。その分、VPS側で公開鍵に接続元と実行内容の制限を付けました。
restrict,command="<受信スクリプト>",from="<報告元PCのTailscaleアドレス>" ssh-ed25519 AAAA... nasmonrestrict：ポート転送、エージェント転送、端末利用などを制限するcommand=：鍵で接続したとき、指定した受信スクリプトだけを実行するfrom=：接続元を報告元PCのアドレスに限る
受信スクリプトは、決められた形式の1行だけを受け付け、それ以外は記録して拒否します。導入前の試験では、この鍵で任意コマンドの実行やポート転送を試し、拒否されることを確かめました。
この制限で、鍵を持つ人がどこからでもVPSを操作できるわけではありません。ただし、報告元PCそのものが侵害された場合には、偽の報告を送られる可能性が残ります。この仕組みはバックアップ処理の実行と結果報告を見張るもので、保管データの内容や復元可能性まで保証するものではありません。
毎朝だけ届かない通知
準備中、VPSの既存の監視が毎朝8時55分に送る定期報告が、ある日から届かなくなっていることに気づきました。記録には、通知サービスからの送信上限超過（HTTP 429）が残っていました。
こちらから送る通知は1日に数通です。調べると、ntfy.shでは送信元のIPアドレスなどを基準に利用枠が管理され、IPv6では標準設定で同じ「/64」の範囲が一つの利用者として扱われます。このVPSのIPv6アドレスは、/64の範囲を他の利用者と共有していました。ログの状況から、同じ範囲を使う別の利用者の通信で枠に達した可能性が高いと考えました。
ntfy.shの枠はUTCの日付で切り替わります。日本時間では午前9時です。そのため、9時前に送る定期報告だけが失敗していました。
対策として、通知を送るcurlに-4を付け、IPv4で送るようにしました。このVPSではIPv4アドレスを他の利用者と共有していないため、以後は同じ上限超過が起きていません。
新しい監視の通知も朝に届くため、本番稼働の前に通知経路の問題を見つけられたのは幸いでした。
本番に触れずに確かめる
組合のバックアップ処理に手を入れるため、試験では本番への影響を避けることを優先しました。
- 変更前と変更後のスクリプトを同じ条件で動かし、終了コード、実行記録、失敗メールの件数が変わらないことを確認する
- 本番スクリプトの複製を試験に使い、NASの場所は存在しないパスに、失敗メールの宛先は自分一人に差し替える
- 本番へ適用する前にバックアップが動いていないことを確認し、適用後の内容が試験したものと同じであることを照合する
作業の多くはAI（Claude Code）と分担しました。AIが手順や確認コマンドを組み立て、私がバックアップ用PCで実行して結果を返す形です。各段階で結果を確かめてから次へ進みました。
その中で、AIが示した試験コマンドに見落としが一つありました。二重起動を再現するために試験用のロックを取得し、あとで止める手順でしたが、そのままでは子プロセスがロックを保持し続け、次の試験まで二重起動と判定される構成でした。実行前に気づき、flockに-oを付けて修正しました。AIに任せる作業が増えても、実行前にコマンドを読み、挙動を確かめることは欠かせません。
13日分の稼働状況
10月16日に本番で動かし始め、10月28日までの13日分を確認しました。
| 項目 | 結果 |
|---|---|
| 毎日の判定 | 13日分すべてDrive・USBとも成功 |
| 報告の送信 | 26回（開始・結果を各13回）、失敗0回 |
| 最長の実行時間 | 約12分40秒（ファイルの大きな整理があった日） |
| 受信側が拒否した報告 | 本番稼働後は0件。拒否記録は導入前の試験で意図的に送ったもの |
普段のバックアップは1〜3分で終わりますが、ファイル整理があった日は、その10倍近くかかりました。朝6時から判定する設定にしたのは、こうした日を「まだ終わっていない」と早まって知らせないためです。この日の結果報告は2時13分に届いており、判定には間に合っていました。
正常な日は何も届きません。毎朝届くのは、見張り役自身の定期報告だけです。
おわりに
バックアップは、取っていることと同じくらい、予定どおり取れたかを確かめることが大切です。その確認役をバックアップ元と同じ場所に置くと、元のPCが止まったときに確認役も止まってしまいます。
今回は、既存のVPSとシェルスクリプト、cron、無料の通知サービスを使って、報告が来ない場合も異常として扱うようにしました。大がかりな監視ツールを導入しなくても、処理する側から独立した場所で報告を待つ仕組みは作れます。
ただし、この監視で確認できるのは、バックアップ処理が報告した成否までです。データが実際に復元できることを確かめるには、別途、定期的な復元試験が必要です。監視と復元確認を組み合わせて、初めて「いざというときに戻せる」備えになります。
参考資料
＼ 最新情報をチェック ／
