自動バックアップは成功した？systemd timerとresticを3分で確認する【Ubuntu Server 26.04】

前回は、Ubuntu Server 26.04 LTSでsystemd timerとresticを使い、自動バックアップの仕組みを作りました。正直にいうと、前回は設定と安全対策が多く、初心者には難しめの内容です。

今回は難易度を下げます。設定ファイルは触らず、自動バックアップが成功したかを3分で確認するだけです。見るのは「次回予定」「直近の終了結果」「最新スナップショット」の3つ。黄・赤のときだけログを開きます。

この確認で分かるのは、直近の自動処理が予定どおり終わり、スナップショットが作られたかどうかです。バックアップから本当に復元できることや、保存データ全体の健全性までは保証しません。復元テストとrestic checkは別の定期点検として続けます。

前提は、systemd timerでresticバックアップを自動化する手順が完了していることです。サービス名などを変更した場合は、自分の名前へ読み替えてください。

この記事では修復しません。

設定変更、再実行、forget、prune、unlock、repairは行いません。異常があれば、表示を記録して止まります。

3分チェックはこの3つだけ
1. 次回予定を見る
2. 直近の終了結果を見る
3. 最新スナップショットを見る
青・黄・赤の判断
黄・赤ならログを50行だけ見る
3分チェックリスト
まとめ

3分チェックはこの3つだけ

予定、実行結果、スナップショットの3項目を順番に確認する図 — 見る場所は3つだけです。予定、実行結果、保存結果の順に確認します。

timerに次回の実行予定がある
serviceの直近結果が成功している
resticに最近のスナップショットがある

大事なのは、1つだけを見て成功と決めないことです。3つがそろって初めて「青」と判断します。

1. 次回予定を見る

systemctl list-timers --all --no-pager \
  ouchi-lab-restic-backup.timer

NEXTに次回の日時、LASTに前回の日時が表示されているか見ます。次の予定があり、前回日時も想定した周期内なら1つ目は青です。

前回日時が古い場合は黄です。対象行が出ない、またはNEXTがn/aなら、次回実行を確認できないため赤です。ここでは有効化や再起動をせず、次へ進みます。

2. 直近の終了結果を見る

systemctl show ouchi-lab-restic-backup.service \
  -p ActiveState -p SubState -p Result \
  -p ExecMainStatus -p ExecMainExitTimestamp

次の3つを確認します。

Result=success
ExecMainStatus=0
ExecMainExitTimestamp=が直近の予定日時と合う

3つがそろえば2つ目は青です。Result=exit-code、ExecMainStatusが0以外なら赤。値が空、日時が古い、予定と合わない場合や、ActiveState=activatingなど実行中の場合は黄です。

なお、短い処理を実行して終了するType=oneshotのserviceは、成功後にinactive (dead)と表示されても異常とは限りません。ここではactiveかどうかではなく、Resultと終了コードを見ます。

3. 最新スナップショットを見る

YOUR_USERを、自動バックアップを実行している一般ユーザー名へ置き換えます。パスは前回の記事どおりの場合です。

sudo -u YOUR_USER env \
  RESTIC_REPOSITORY=/mnt/backup-drive/restic/ouchi-lab \
  RESTIC_PASSWORD_FILE=/home/YOUR_USER/.config/restic/ouchi-lab-password \
  restic snapshots --tag ouchi-lab-nginx --latest 1

1行のスナップショットが表示され、Dateが直近の予定日時と同じ頃、Tagsにouchi-lab-nginx、Pathsに前回設定した対象があれば3つ目も青です。

何も出ない、日時が古い、パスワードやリポジトリのエラーが出る場合は赤です。複数行が出た場合は、自分で1件を選ばず黄にします。--latest 1はホストとパスの組み合わせごとに最新1件を表示するため、構成が増えると複数行になることがあります。

青・黄・赤の判断

自動バックアップを青、黄、赤の3段階で判断する図 — 3項目すべてがそろったら青。1つでも判断できなければ黄、明確な失敗は赤です。

青：次回予定、直近結果、最新スナップショットの3つがすべて正常
黄：値が空、日時が古い、予定と結果が合わないなど、成功か判断できない
赤：終了コードが0以外、Resultが失敗、またはresticがエラー

黄は「たぶん大丈夫」ではありません。青に必要な3項目がそろわなければ、ログ確認へ進みます。

黄・赤ならログを50行だけ見る

バックアップ失敗時にログを確認して記録し、設定を変えずに止まる流れ — 黄・赤のときはログを控えて止まります。その場で削除や修復を始めません。

sudo journalctl -u ouchi-lab-restic-backup.service \
  --invocation=0 --no-pager

直近の実行ログから、最初のエラーと終了ステータスを日時と一緒に記録します。SSD未マウント、古いバックアップ、ロック競合など、前回の記事で決めた終了理由が表示される場合があります。

ここでやるのは読む・記録する・止まるまでです。ログが長くても、推測で設定を変えたり、ロックファイルやスナップショットを削除したりしません。

3分チェックリスト

NEXTに次回予定がある
Result=successかつExecMainStatus=0
終了日時が前回予定と合う
同じ頃のresticスナップショットがある
タグがouchi-lab-nginx
3つ全部そろったときだけ青にした

まとめ

自動バックアップの確認は、仕組みを全部理解してからでなくても始められます。予定、終了結果、保存結果の3つを順番に見れば、動いているつもりの見落としを減らせます。

systemctl list-timersとshowはUbuntu 26.04のsystemctlマニュアル、unit単位のログ表示はjournalctlマニュアル、resticの一覧とタグによる絞り込みはrestic公式のリポジトリ操作とスクリプト向け出力で確認しました。公式情報の確認日は2026年8月4日です。

次回は、今回見つけた黄・赤をもとに、バックアップ失敗の原因を「SSD」「元データ」「restic」の3系統へ分けて調べる方法を扱います。