自動バックアップは直った？3つの証拠で正常復帰を確認する【Ubuntu Server 26.04】

前回は、自動バックアップの失敗原因を「外付けSSD」「元データ」「restic」の3つへ切り分け、見直す場所を特定しました。今回は、その見直し後に自動バックアップが本当に正常へ戻ったかを確認します。

確認方法は単純です。serviceを何度も手動実行せず、次回のtimer実行を1回待ちます。そのあと「systemdの終了結果」「最後まで進んだログ」「新しいresticスナップショット」の3つがそろえば完了です。

この手順で確認できるのは、1回の自動バックアップが安全確認、backup、snapshot確認、restic checkまで正常に終わったことです。実際に復元できることや、保存済みデータをすべて読み取れることまでは保証しません。

前提は、11本目の原因切り分けで原因候補を特定し、対応する過去記事を見直したことです。

手動のstartやrestartは実行しません。

次回のtimer実行を1回だけ待ちます。これにより、service単体ではなく、普段使う自動実行の経路が戻ったことを確認できます。

なぜ手動実行せず、次回のtimerを待つのか
1. 次回の自動実行時刻を確認する
2. 実行中ではないことを確認する
3. 最後まで進んだ完了ログを確認する
4. 新しいresticスナップショットを確認する
3つの証拠がそろったら正常復帰
実行中・75・再失敗なら止まる
この記事で実行しない操作
まとめ

なぜ手動実行せず、次回のtimerを待つのか

手動実行を繰り返さず、次回のtimer実行を1回だけ待つ流れ — 実運用と同じ経路を確かめるため、serviceを手動で連打せず、次回のtimer実行を1回待ちます。

手動でserviceを起動すると、すぐに確認できる反面、timerの復旧確認にはなりません。前段の.tgz生成と時刻が重なったり、別の処理と競合して終了コード75になったりする可能性もあります。

今回は「毎日の自動バックアップが戻ったか」が目的です。いつものtimerに1回だけ任せる方が、初心者にも判断しやすく、実運用に近い確認になります。

1. 次回の自動実行時刻を確認する

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

NEXTの日時を控えます。NEXTがn/a、または対象行が出ない場合は自動実行を確認できないため、先へ進まず11本目へ戻ります。

NEXTが表示されていれば、その時刻を過ぎるまで待ちます。timerには精度幅やランダム遅延が設定されている場合があるため、表示時刻ちょうどに結果が出なくても異常とは限りません。

2. 実行中ではないことを確認する

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

ActiveState=activeやactivatingなら実行中です。何も操作せず待ち、終了後に同じコマンドをもう一度だけ実行します。

実行後は次の5点を確認します。

Result=success
ExecMainCode=exited
ExecMainStatus=0
ExecMainStartTimestampが今回待ったtimer実行の時刻以降
ExecMainExitTimestampが開始時刻より後

前回の失敗結果が残っている場合もあるため、日時が新しくなったことまで確認します。3つの成功証拠の1つ目は、これで完了です。

短い処理を終えて終了するType=oneshotのserviceは、成功後にActiveState=inactive、SubState=deadでも正常です。activeかどうかだけで判断せず、終了結果と時刻を見ます。

3. 最後まで進んだ完了ログを確認する

sudo journalctl \
  --unit=ouchi-lab-restic-backup.service \
  --invocation=0 \
  --grep='restic二次バックアップと検査が完了しました' \
  --no-pager

この完了メッセージは、SSDと元データの確認、restic backup、snapshot確認、restic checkがすべて成功した後だけ出ます。最新実行の日時で1行表示されれば、2つ目の証拠は完了です。

何も表示されない場合は「ログが途中で止まった」と判断します。推測で成功扱いせず、最新ログ全体を確認する11本目へ戻ります。

4. 新しいresticスナップショットを確認する

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 --host "$(hostname)" \
  --tag ouchi-lab-nginx --latest 1

YOUR_USERを自動バックアップの実行ユーザー名へ置き換えます。表示されたスナップショットのDateが今回のExecMainStartTimestampからExecMainExitTimestampまでの間で、Tagsにouchi-lab-nginx、Pathsに元バックアップのパスがあれば、3つ目の証拠も完了です。

古いスナップショットしかない、何も表示されない、複数の候補が出て特定できない場合は正常復帰と判断しません。

3つの証拠がそろったら正常復帰

systemdの成功結果、完了ログ、新しいresticスナップショットの3つを確認する図 — 正常復帰は、systemdの結果・最後まで進んだログ・新しいスナップショットの3つで判断します。

今回のtimer実行後に、systemdがsuccess / exited / 0
最新実行のjournalに最後の完了メッセージがある
実行開始後の新しいタグ付きスナップショットがある

この3つが同じ実行日時でそろったら、今回の正常復帰確認は完了です。timerのNEXTも次回日時へ進んでいれば、自動実行の予定も継続しています。

実行中・75・再失敗なら止まる

実行中

ActiveState=activeまたはactivatingなら待ちます。途中で別の確認コマンドを重ねたり、serviceを再起動したりしません。

終了コード75

別の処理が動き、排他ロックを取得できなかった可能性があります。ロックファイルを削除せず、手動再実行もしません。今回の正常復帰確認は未完了とし、次の定期実行後にもう一度確認します。

再失敗

Resultがsuccess以外、ExecMainCodeがexited以外、ExecMainStatusが0以外なら再失敗です。新しいコードと最初のエラーを使い、11本目の切り分けを最初からやり直します。

この記事で実行しない操作

systemctl start、restart、reset-failed、mount、umount、chmod、chown、restic backup、forget、prune、unlock、repair、ファイルやロックの削除は行いません。

まとめ

見直し後の確認では、急いで手動実行する必要はありません。次回のtimerを1回待ち、systemdの終了結果、完了ログ、新しいスナップショットの3つを同じ実行日時で確認します。

timerが対応serviceを起動する仕組みと遅延はUbuntu 26.04のsystemd.timerマニュアル、最新実行とメッセージの絞り込みはjournalctlマニュアル、snapshotの一覧と絞り込みはrestic公式のリポジトリ操作、終了コードの扱いはrestic公式Scriptingで確認しました。公式情報の確認日は2026年8月6日です。

次回は、毎日の確認を忘れないために、削除や修復を行わないローカル監視の作り方を扱います。