自動バックアップが失敗したら？SSD・元データ・resticの3つに切り分ける【Ubuntu Server 26.04】

前回は、自動バックアップが青・黄・赤のどれかを3分で確認しました。今回は、その結果が黄または赤だったときの続きです。

少し難しそうに見えますが、ログを全部読む必要はありません。「最新ログを見る→終了コードを見つける→当てはまる1か所だけ確認する」の順で進めます。原因候補を自分で特定し、次に見直す場所を決めるための記事です。

この手順で分かるのは、失敗が「外付けSSD」「resticへ渡す前の元データ」「resticの実行環境」のどこにありそうかです。既存バックアップの健全性や、実際に復元できることまでは証明しません。

前提は、systemd timerでresticバックアップを自動化する手順と、自動バックアップの3分チェックが完了していることです。

最初に見るのは最新1回のログだけ

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

--invocation=0は、このserviceの最新1回の実行を指定します。上から順に読み、最初のエラー、終了コード、時刻、対象パスを控えます。すべての行を理解しなくても大丈夫です。

終了コードが見つけにくい場合は、systemdが記録した結果だけを表示します。

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

ExecMainStatusの数字を、次の表へ当てはめます。

先にExecMainCode=exitedであることを確認します。この場合だけ、終了コード表を使えます。killedやdumpedなど別の値なら、表へ当てはめず「通常の終了ではなかった」と判断して変更せず終了します。20〜75はrestic共通ではなく、9本目で作ったバックアップスクリプト独自の終了コードです。

数字だけで機器の故障やリポジトリ破損を断定しないのがポイントです。該当する節を1つだけ確認し、「何が想定と違うか」を言葉にできたら切り分け完了です。

20〜26なら外付けSSD側を見る

findmnt --mountpoint /mnt/backup-drive \
  --output TARGET,SOURCE,FSTYPE,OPTIONS,UUID

1行表示されるか、TARGETが/mnt/backup-driveか、UUIDが9本目で控えた値と同じかを見ます。OPTIONSがroなら読み取り専用、rwなら読み書き可能としてマウントされています。

何も表示されない、UUIDやマウント先が違う、ログに「SSD配下ではない」「書き込めない」と出る場合は、SSD側に原因候補ありです。ただし、SSD本体の故障とは限りません。接続・マウント・パス・権限のどこかまでの切り分けです。

この節の完了条件：「マウントされていない」「別のUUID」「読み取り専用」「想定外のパス」のどれかを特定できたら完了です。すべて想定どおりならSSD側は現在正常と判断し、最新ログの最初のエラーへ戻ります。設定の見直し先は、9本目のSSD・UUID設定です。

40〜45なら元データ側を見る

find "$HOME/docker/nginx-lan/backups" -maxdepth 1 -type f \
  ( -name '*.tgz' -o -name '*.sha256' ) \
  -printf '%TY-%Tm-%Td %TH:%TM  %s bytes  %f\n'

新しい.tgzと、同じ名前に対応する.sha256があるか、更新日時が想定より古くないかを見ます。

• 40：元ディレクトリを読めない
• 41：.tgzがない
• 42：対応する.sha256がない
• 43：保存済みSHA-256と一致しない
• 44〜45：更新日時が未来、または古すぎる

当てはまれば、resticへ渡す前の元データ側に原因候補ありです。43でも、ここではファイルを作り直したり削除したりせず、対象ファイル名を記録します。

この節の完了条件：「tgzがない」「SHA-256がない」「一致しない」「日時が不正」のどれかを特定できたら完了です。すべてそろっていれば元データ側は現在正常です。作成手順の見直し先は、7本目のバックアップ作成・SHA-256確認です。

27〜31やresticのエラーなら実行環境を見る

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 cat config

リポジトリの設定が表示されれば、読み取りと認証はできています。エラーなら、その文をそのまま記録します。パスワードファイルの内容は表示しません。

27〜31は、リポジトリの場所や書き込み条件、パスワードファイルの有無・モード・所有者などの候補です。restic自身も、一般的な失敗、元データの一部を読めない、リポジトリがない、ロック失敗、パスワード不一致、中断を別の終了コードで返します。非0だから「リポジトリが壊れた」とは判断しません。

• 3：元データの一部を読めない
• 10：リポジトリが見つからない
• 11：リポジトリのロックを取得できない
• 12：パスワードが一致しない
• 130：処理が中断された

この節の完了条件：restic cat configの結果から、「リポジトリの場所」「認証」「ロック」「保存先」のどこで止まったかを特定できたら完了です。すべて読めるなら、ログに出たbackup、snapshots、checkのどれが失敗したかを確認します。設定の見直し先は、8本目のrestic初期設定です。

64・75・不明は3つへ無理に分けない

64：必須設定が空

SSD・元データ・resticのどれかではなく、設定不足として別枠にします。ログに出た空の設定名を特定し、9本目で作ったserviceと環境設定の同じ項目を見直します。値や秘密情報は画面へ表示しません。

75：別の処理が動いている可能性

排他ロックを取れず、二重実行を避けるために止まった可能性があります。故障扱いせず、ログの時刻とtimerの次回予定を確認します。手動で再実行せず、次回の定期実行後に3分チェックをやり直します。ロックファイルは削除しません。

その他・コード不明：最初のエラーから分類する

最初に失敗した行のコマンド名と対象パスを見ます。findmntや/mnt/backup-driveならSSD、tgzやsha256なら元データ、resticならrestic側です。どれにも当てはまらなければ設定を変えず「分類できない」と確定します。restic公式も未知の終了コードを成功扱いしないよう案内しています。

自己解決メモに残す4点

• 確認日時
• Result、ExecMainCode、ExecMainStatus
• ログで最初に出たエラー
• 読み取り専用確認で分かったこと

この4点を同じメモへ残すと、別の実行結果と混ざらず、見直す場所が明確になります。メモは外へ公開せず、パスワード、トークン、パスワードファイルの中身は書きません。

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

systemctl start、restart、reset-failed、mount、umount、chmod、chown、restic backup、forget、prune、unlock、repair、fsck、ファイルの削除・移動・名前変更は行いません。

まとめ

難しいログでも、全部を読む必要はありません。最新ログ→終了コード→該当する1か所の順で見れば、原因を「SSD」「元データ」「restic」へ安全に切り分けられます。各節の完了条件まで進み、原因候補と見直す記事を自分で選べたら完了です。

最新実行の指定はUbuntu 26.04のjournalctlマニュアル、マウント情報の確認はfindmntマニュアル、終了コードはrestic公式のスクリプト向け資料、トラブル時の確認はrestic公式トラブルシューティング、排他ロックはflockマニュアルで確認しました。公式情報の確認日は2026年8月5日です。

次回は、原因を見直したあとに、自動バックアップが正常へ戻ったかを安全に再確認する手順を扱います。