技術ガイド · 実用ガイド
rsyncの終了コード24：警告を無視する前に消えたファイルを確認
コード24は転送中にソースファイルが消えたことを示します。パスと元の状態を保存し、重要性を判断して安定したソースでの再実行を確認してから自動化方針を変えます。ラッパーで欠落が完全なバックアップになるわけではありません。
rsyncの終了コード24はソースファイル消失による部分転送です。他のエラーによる部分転送を示す23とは異なります。発見後に消えるのは稼働中の通常変化かもしれませんが、一時的なロックか重要データの唯一のコピーかは終了状態だけでは分かりません。
1. 警告を消す前に実行記録を保存
標準出力と標準エラー、日時、両側のrsync版、正確なソース・宛先ルート、末尾スラッシュの扱い、フィルターと削除オプションを保存します。rsync終了直後に実際の終了状態を取得してください。後のコマンドやパイプでは記録ツールの状態になる場合があります。消失パスをバックアップ識別情報と一緒に残します。
次の管理された試行では--itemize-changesで予定・実際の変更を見られ、--log-file=FILEで転送活動を保存できます。ただし活動ログを標準エラーの代わりと考えません。一つの消失パスから、削除・改名・アクセス不能か別のソース表示では存在するかを確認します。広い警告フィルターで唯一の証拠を消さないでください。
2. 受け入れられる欠落を判断
アプリやデータの責任者にパスの内容を尋ねます。捨ててよいロックや一時ファイルは対象外かもしれませんが、メール、文書、重要なアプリ状態は忙しいディレクトリだから不要にはなりません。欠落を許容する方針がある場合だけ、狭く確認済みの除外を記録します。全tmpフォルダーやロック拡張子の除外は必要データを隠しかねません。
2023年のBack In Time issueにはコード24でキャンセルされた実際のスナップショットがあります。保守者は24を情報として記録し、他エラーをエラーのままにする変更をマージしたと報告しました。製品別方針であり、全利用者の欠落が無害という証拠ではありません。安定した重要パスが繰り返し消えたりマウント・I/Oエラーが伴ったりするなら、状態変更より先にソースを調べます。
3. 検証できるソースで再実行
削除付きコマンドを再実行する前に、同じ確認済みルートとフィルターに--dry-run --itemize-changesを加え、特に削除予定を見ます。試行はコピーも以前の欠落修復もしません。計画した静止時間やアプリ対応スナップショット手順で変化を減らします。変化するアプリへの稼働中rsyncだけでは時点整合性のあるバックアップになりません。
承認された実転送の後、必要内容と各重要消失パスの結果を確認します。既定のクイックチェックはサイズと更新時刻を使い、--checksumは内容チェックサムによる選択に変えてファイル読み取りを増やします。動くソースを安定させる機能ではなく、転送済みファイルの通常の再構築検証とも別です。ゼロ終了だけでなく代表的な復元内容やアプリ指定の復元テストを確認します。
4. 根拠のある方針だけ変更
公式FAQのラッパーは24だけを0にし、他の状態を保持します。予想される欠落と許容結果を記録した後だけ採用し、元の24をログや監視に残します。|| trueで全失敗を成功にしないでください。重要欠落が不明なら、ラッパーがゼロでも目的に対して不完全です。
似た名前の二つのオプションは別物です。--ignore-missing-argsは初回検索で存在しない明示ソース引数のエラーを抑えますが、最初に見つかって後で消えたファイルには効かないと手引きが明記します。--ignore-errorsはI/Oエラーがあっても--deleteを進めます。どちらも欠落を復元しません。必要データが使え、全欠落が説明され、他失敗が見えることが完了であり、警告消失だけではありません。
