技術ガイド · 実用ガイド
tarの「file changed as we read it」：警告を消す前にパスを確認
正確なパスと元の終了状態を保存し、ディレクトリ変化とアプリのデータ変化を分けます。読めるアーカイブや消えた警告だけでは復元可能なバックアップになりません。
GNU tarの「file changed as we read it」はパス別の確認が必要です。アーカイブ全体が無用とも無害とも即断できません。作成、追加、更新時の終了コード1はファイルが変化し、ファイル集合の正確なコピーではないことを示します。バックアップ処理方針を変える前に証拠を残します。
1. パスを記録し、入力と出力を分ける
正確なコマンド、GNU tar版、作業ディレクトリ、入力ルート、除外、出力先、日時、標準エラー全体を保存します。終了直後にtar自身の状態を取得します。後のコマンドやパイプ最後のプロセスでは隠れることがあります。圧縮器やI/O失敗も残します。ファイルの警告と「.」ディレクトリの警告では調べ方が違います。
出力先を入力ツリーと照合します。ツリー内で作成しているなら、管理された再実行では別の場所へ移し、必要入力が選ばれるか確認します。出力ファイルを除外しても、作成で親ディレクトリが変わる場合があります。警告を消すためだけに確認済みの集合をシェルのワイルドカードへ置換しないでください。隠しファイルの選択が変わり得ます。
2. データ変化とファイルシステム挙動を分類
責任者に、パスが捨ててよいキャッシュ、稼働ログ、静的資産、重要アプリ状態のどれか尋ねます。損失を許容する方針なく全ログ・ロック・一時的に見える名前を除外しません。ディレクトリなら活動とファイルシステム・コンテナ層を調べ、全子ファイルの変更と決めつけません。安定しているはずのソースでも続くなら、版と小さな再現例を残します。
fuse-overlayfsの原issue384は単純診断の限界を示します。報告者は子項目を除外してもルートの警告を示し、観測したディレクトリ時刻を変える小さなプログラムに絞りました。取得した記録ではissueは未解決です。この歴史例は層の確認を支持しますが、現在のコンテナが同じ原因だとも汎用修正があるとも示しません。
3. 整合したソースから再作成して確認
静的資産には静かな確認済み作業コピーを用意し、tarが読む間は更新しません。稼働データベースは自身のバックアップ手順を使い、コピーだけで十分と考えません。現行PostgreSQL文書は通常のファイルコピーで停止、または必要WALを含む正しく整合したスナップショットを要求します。複数ボリュームは協調が必要で、接続禁止やライブコピー反復だけでは同等になりません。
承認ソースから別名アーカイブを作り、出力と状態を保存します。隠しファイルや意図した除外を含む必要一覧とメンバーを照合します。適切なら安定ソースと比較し、隔離した試験場所へ代表的内容を復元します。一覧だけでアプリ復元は証明できません。状態を持つデータはアプリ指定の確認を行い、代替が条件を満たすまで元アーカイブを保存します。
4. 警告抑制は別の方針として扱う
GNU tarの--warning=no-file-changedはメッセージ制御です。--ignore-failed-readは読取失敗が完了状態へ及ぼす扱いを変え、単一メッセージの非表示より広いものです。変化するデータの整合や欠落復元はしません。古いWindows・コンテナ・tarの回避策を写す前に、導入版文書と実際の状態を確認します。
正確なパスと許容変化が分かり、必要内容が使え、他失敗が見える場合だけ受け入れます。|| trueで全非ゼロを成功にしたり、標準エラー全体を捨てたり、ラッパーのゼロを復元準備完了と考えたりしません。重要データ、原因不明、復元失敗なら未解決のままにし、ソースやアプリのバックアップ方法を調査します。
