resticバックアップ通知を送信前にdry-run確認する方法｜Ubuntu Server 26.04

resticバックアップヘルスチェックの結果を通知文へ変換し外部送信せずローカル確認する流れ はじめての自宅サーバー

14本目では、読み取り専用ヘルスチェックをsystemd timerで定期実行し、結果をローカルjournalへ残しました。次に考えたくなるのが、YELLOWやREDを見逃さないための通知です。

ただし、いきなりメールやWebhookへ接続すると、誤送信、秘密情報の混入、同じ障害の連続送信が起きやすくなります。15本目では外部へ送らず、実際に送る予定の通知文だけをdry-runで作って確認します。

この記事では送信しません

Webhook、メール、チャット、外部APIへの通信は行いません。トークンやURLも用意しません。確認するのはヘルスチェック結果から作ったローカルのプレビューだけです。

到達点と扱わないこと

  • 到達点: GREEN / YELLOW / REDから、同じ書式の通知プレビューを1コマンドで表示する
  • 到達点: 終了コード0 / 1 / 2をそのまま呼び出し側へ返す
  • 非目標: 外部送信、秘密情報の読み込み、自動修復、再実行、通知抑制の本番運用

通知文に必要な5項目

GREEN YELLOW REDの終了コードを通知文の項目と次の行動へ対応付けた一覧
通知文は色だけでなく、時刻・ホスト・根拠・次の行動を固定順で並べます。
  1. 確認時刻
  2. ホスト名
  3. GREEN / YELLOW / REDと終了コード
  4. ヘルスチェックが返した1行要約
  5. 人が次に確認する場所

snapshotの全文、環境ファイル、パスワードファイル、Webhook URLは含めません。通知文は原因を断定する場所ではなく、調査を始めるための索引です。

dry-runスクリプトを配置する

完成版はリポジトリのexamples/ouchi-lab-backup-notification-preview.shです。13本目の固定パスにあるヘルスチェックだけを呼び出し、最初の1行と終了コードを通知プレビューへ変換します。

sudo install -o root -g root -m 755 \
  ./ouchi-lab-backup-notification-preview.sh \
  /usr/local/sbin/ouchi-lab-backup-notification-preview

sudo /usr/bin/bash -n \
  /usr/local/sbin/ouchi-lab-backup-notification-preview

スクリプト内には送信先、認証情報、通信コマンドを置きません。固定したヘルスチェック以外の任意コマンドを引数から受け取らない設計にします。

1コマンドで通知プレビューを作る

sudo /usr/local/sbin/ouchi-lab-backup-notification-preview
status=$?
printf 'preview_exit=%s
' "$status"

正常時の例です。時刻やsnapshot IDは環境ごとに変わります。

DRY_RUN=true
SEND_ENABLED=false
checked_at=2026-08-08T07:00:00+09:00
host=home-server
result=GREEN
exit_code=0
summary=ouchi-lab-backup-health: GREEN: 3つの証拠が一致しました
next_action=対応不要。次回の定期確認を待つ
preview_exit=0

終了コードを消さない

プレビュー生成に成功しても、元のヘルスチェックがREDなら終了コードは2のまま返します。通知文が作れたことと、バックアップが正常なことは別だからです。

結果 終了コード 次の行動
GREEN 0 次回の定期確認を待つ
YELLOW 1 timerと直近時刻を確認
RED 2 journalから原因切り分け
未知 元の値 スクリプトと実行環境を確認

秘密情報が混ざっていないか確認する

sudo /usr/local/sbin/ouchi-lab-backup-notification-preview \
  | grep -E 'PASSWORD|TOKEN|WEBHOOK|https?://'

何も表示されないことを確認します。ただし、このgrepだけで完全な安全を保証できるわけではありません。環境ファイルの内容を出力していないこと、出力対象を最初の1行に限定していることもコードで確認します。

dry-runの安全境界

通知dry-runで許可するローカル確認と禁止する外部送信や自動修復の境界
dry-runではローカル表示とjournal確認まで。外部送信や自動修復は行いません。
  • 行う: ローカルのヘルスチェック実行、結果の整形、標準出力、終了コードの引き継ぎ
  • 行わない: curlやメール送信、Webhook、外部DNS接続、トークン読込、自動修復、バックアップ再実行

dry-runスクリプトをsystemd timerへ組み込むのもまだ先です。まず手動でGREEN / YELLOW / REDの3パターンをレビューし、文面と情報量を確定します。

安全に検証するチェックリスト

  1. bash -nが無出力で終わる
  2. DRY_RUN=trueとSEND_ENABLED=falseが毎回表示される
  3. 終了コードが元のヘルスチェックと一致する
  4. パスワード、トークン、URL、環境ファイル内容が出ない
  5. ネットワーク通信コマンドと自動修復コマンドがない

まとめ

15本目では、バックアップヘルスチェックの結果を通知文へ変換し、外部送信せずローカルで確認するdry-runを作りました。先に文面、終了コード、秘密情報の境界を固めておけば、将来通知先を追加するときも「判定」「文面」「送信」を分離できます。

次に外部通知へ進む場合も、送信先の秘密情報管理、連続通知の抑制、GREEN復旧通知、タイムアウトを別々に設計してから有効化します。

コメント

タイトルとURLをコピーしました