これをデバッグする方法は？この問題は、過去数日以内に突然現れました。Webサイトのすべてのバックアップが破損しています。

バックアップをそのままにしておけばtar問題はありませんが、tarが圧縮されるとすぐに、gzまたはxz解凍できなくなります。

空きディスクがたくさんあります

Local disk space    2.68 TB total / 2.26 TB free / 432.46 GB used

エラー

tar: Skipping to next header[===============================>                                                    ] 39% ETA 0:01:14
tar: A lone zero block at 2291466===============================>                                                ] 44% ETA 0:01:13
tar: Exiting with failure status due to previous errors
 878MiB 0:00:58 [15.1MiB/s] [===================================>                                                ] 44%

そして、なぜそれは言うのSkipping to next headerですか？それはこれまでに行ったことがない。いくつかのファイルがひどく間違っています。

ディレクトリには約15kのpdf、jpg、またはpngファイルがあります。

コマンド

pv $backup_file | tar -izxf - -C $import_dir

圧縮を破壊するいくつかのデータがなければなりません。

私はこれをすることによってHDDの健康をチェックすることも試みました：

# getting the drives
lsblk -dpno name

smartctl -H /dev/sda
smartctl -H /dev/sdb

両方のドライブで私はこれを取得します：

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

tar.gzを破損しているファイルを見つけるにはどうすればよいですか？削除したいだけです。

更新

すべてのファイルを別のサーバーにコピーしたところ、まったく同じ問題が発生しました。すべてをtar形式で圧縮して問題なく抽出できますが、ファイルを圧縮したいので、解凍することはできません（gz / xz）。

ファイルが切り捨てられているか破損しているためxz、データの最後に到達できません。tarアーカイブが途中で停止するため、文句を言いxzます。これは、データ全体を読み取ることができなかったため、論理的です。

次のコマンドを実行して、問題の場所を確認します。

cat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
xzcat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null

問題がある場合catは、ファイルがディスク上で破損し、オペレーティングシステムが破損を検出しました。詳細については、カーネルログを確認してください。通常、この時点でディスクを交換する必要があります。xz不平を言うだけの場合、OSは破損を検出しませんでしたが、ファイルは無効です（破損または切り捨てられています）。いずれにしても、このファイルを回復することはできません。オフラインバックアップからそれを取り戻す必要があります。

壊れたtarファイルがどのように作成されるかについての言及はありませんか？

Webサイトからのバックアップだとおっしゃっていますが、表示されている問題はすべて復元/解凍の際のものなので、トラブルシューティングを行う必要があるのは（ソース）です。

バックアップを別のマシン/場所に移動した後でファイルを圧縮解除できない場合は、ファイルが不良であるか、トランスポートで破損している必要があります。

エラーの原因を特定するには：

• Webサーバーに手動でバックアップを作成します（なしpvとなし-i）
• Webサーバー上のバックアップを手動でテストします（なしpvとなし-i）

これまでに問題が見つからなかった場合：

• Webサーバーからバックアップをコピーする
• ターゲットマシンでコピーしたバックアップをテストします（なしpvとなし-i）

これまでに問題が見つからなかった場合、バックアップスクリプトは、手動で行った場合と同じ方法でアーカイブを作成しません（手動で行ったように変更する必要がある可能性があります）。

また、関連するすべてのコマンドの絶対パスを使用してください。システムに不正な変数$PATHや$LD_LIBRARY_PATH変数があり、侵入者がいる場合は、トロイの木馬型バイナリを使用している可能性があり、意図しない副作用が発生する可能性があります。

もちろんtar、両方のシステムがdebianでない限り、互換性のないバージョンが含まれる可能性もあります。両側でPOSIXモードを強制することもできます。

-i長い形式でであるフラグを使用しています--ignore-zeros。これが、破損したファイルについてtarが文句を言わない理由です。したがって、tarファイルをデバッグする-i場合は、オプションを削除するだけで、破損したファイルのリストが表示されます。

UNIXで破損したファイルを見つけるには、他にも2つの方法があります（一般的に）。別の質問の答えを引用します。

rsyncを使用してディレクトリをコピーすることができ、エラーが原因でrsyncが停止した場合は、rsyncを終了した時点からコピーを再開できます。

rsyncの--dry-runオプションを使用すると、実際に何もコピーせずに何がコピーされるかを確認できます。--statsそして--progressオプションも有用であろう。そして、--human-readableまたは-h読みやすいです。

例えば

rsync --dry-run -avh --stats --progress / path / to / src / / path / to / destination /

Mac OS Xにデフォルトでrsyncがインストールされているかどうかはわかりませんが、Macで使用したことがあるので、確実に入手できることはわかっています。

サブディレクトリ内のファイルを読み取ることができるかどうかを簡単に確認するには、を使用できますgrep -r XXX /path/to/directory/ > /dev/null。出力はとにかく破棄されているため、検索正規表現は関係ありません。

STDOUTは/ dev / nullにリダイレクトされるため、エラーのみが表示されます。

ここでgrepを選択した唯一の理由は、その-R再帰オプションのためでした。ここでgrepの代わりに使用できるコマンドは他にもたくさんありますが、findで使用するとさらに多くのコマンドが使用できます。

参考として：破損したファイルを見つける

@MattBiancoが答える推論の行は、この特定の問題を解決するために私が系統的に従うものです。

ゼロ化されたブロックはEOFを示しますが、それはブロック化因数に依存します（デフォルトはコンパイルされた定数で、通常は20です）。タール--compare| （）で暗黙的--diffに実行されているように見えます。--ignore-zeros-i

余分な合併症を考えるとpv、私は疑いtar -iのための問題を引き起こしているxzを見て、要因を遮断する上タール男私が最初に削除することをお勧めしたいです-i

それでも問題が解決しない場合は、次のように置き換えます。

--read-full-records --blocking-factor=300

"tar：A lone zero block at N"とググって読んでいて、何もパイプしていない場合は、を試してください--ignore-zeros。