13本目では、systemdの実行結果、同じInvocation IDのjournal、対象snapshotを突き合わせる読み取り専用ヘルスチェックを作りました。今回はその確認をsystemd timerで定期実行し、結果をローカルjournalへ残します。
ここで追加するのは「確認の自動化」です。バックアップを開始したり、古いsnapshotを削除したり、メールやWebhookを送ったりはしません。問題が起きたときに、まずjournalから事実を読める状態を作る記事です。
安全境界
timerが起動するserviceは、13本目のヘルスチェックだけを呼び出します。start、restart、backup、forget、prune、外部通知は追加しません。
14本目で作る構成
ouchi-lab-backup-health.timerが定刻に起動するouchi-lab-backup-health.serviceがヘルスチェックを1回だけ実行する- 終了コード0/1/2をsystemdとjournalで確認する
- 次回実行時刻と直近結果を読み取り専用コマンドで確認する
serviceユニットを作る
serviceは常駐させず、1回のチェックが終われば終了するoneshotにします。実行ユーザーや環境ファイルは13本目と同じ構成を使い、timer側に秘密情報を書きません。
[Unit]
Description=Read-only backup health check
After=ouchi-lab-restic-backup.service
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/ouchi-lab-backup-health
User=root
timerユニットを作る
まずは毎日1回など、バックアップ完了後に十分な余裕がある間隔から始めます。OnCalendarとPersistentの意味を確認し、サーバー再起動後に意図せず連続実行されないかを見ます。
[Unit]
Description=Run read-only backup health check daily
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
Unit=ouchi-lab-backup-health.service
[Install]
WantedBy=timers.target
配置後に確認するコマンド
sudo systemctl daemon-reload
sudo systemctl enable --now ouchi-lab-backup-health.timer
systemctl list-timers --all ouchi-lab-backup-health.timer
systemctl show ouchi-lab-backup-health.timer -p NextElapseUSecRealtime -p LastTriggerUSec
ここで行っているのはユニットの読み込みとtimerの有効化です。ヘルスチェック本体がバックアップを変更するわけではありません。最初の実行を待つか、検証環境でserviceを単発実行してから結果を確認します。
journalで1回分の結果を確認する
timerの実行履歴とserviceの実行結果は別々に確認します。直近のserviceが終わっていること、終了コードが記事のGREEN/YELLOW/REDと一致すること、実行時刻が想定範囲にあることを確認します。
systemctl status ouchi-lab-backup-health.service --no-pager
journalctl --unit=ouchi-lab-backup-health.service --since "today" --no-pager
systemctl show ouchi-lab-backup-health.service -p Result -p ExecMainStatus -p InvocationID
異常時の読み方
| 状態 | 見る場所 | 次の一手 |
|---|---|---|
| GREEN / 0 | service、journal、snapshot | 次回timerまで待つ |
| YELLOW / 1 | timerの遅延、古い成功、実行中状態 | 次回実行と時刻を確認 |
| RED / 2 | journal、環境ファイル、restic結果 | 11本目の切り分けへ戻る |
timerがactiveでも、直近serviceが失敗していれば正常とは言えません。timerの存在、serviceの結果、ヘルスチェックの出力を混ぜずに読みます。
読み取り専用の境界を守る
- 許可:
systemctl show、systemctl status、journalctl、restic snapshots --json、jq - 禁止: バックアップ開始、prune、forget、unlock、repair、mount、外部通知
timerを追加したことで、確認処理が本番のバックアップ処理へ入り込まないよう、serviceのExecStartは固定パス1本にします。変更操作が必要になったときは、別の手動手順として扱います。
確認チェックリスト
systemctl list-timersでNEXTとLASTが想定どおり- serviceのInvocationIDとjournalの実行単位が一致
- 終了コード0/1/2と記事の色分けが一致
- timerを有効化してもバックアップserviceの設定が変わっていない
まとめ
14本目では、13本目の読み取り専用チェックをsystemd timerで定期実行し、serviceの終了結果とjournalを追跡できるようにしました。定期実行は監視の入口であり、修復や通知までを自動化するものではありません。まずはローカルに残る証拠を毎日確認できる状態を作り、必要になった段階で通知や運用ルールを別途設計します。
コメント