これをデバッグする方法は？この問題は過去2日間に突然現れました。ウェブサイトのすべてのバックアップが破損しています。
バックアップをそのままにしておくと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か？以前は一度も行ったことはありません。いくつかのファイルに深刻な問題があります。
ディレクトリには約15,000個のpdf、jpg、またはpngファイルがあります。
注文する
pv $backup_file | tar -izxf - -C $import_dir
圧縮を破るデータが必要です。
また、次のようにしてハードドライブの状態を確認してみました。
# 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が破損したファイルを見つける方法は？ただ削除したいです。
修正する
これで、すべてのファイルを別のサーバーにコピーしましたが、同じ問題が発生しました。すべてを圧縮して問題なく抽出できますが、ファイルを圧縮したい瞬間に解凍することはできません（gz / xz）。
答え1
ファイルが切り捨てられたか破損しているため、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オペレーティングシステムは破損を検出できませんでしたが、ファイルはまだ有効ではありません（破損または切り捨て）。どちらの方法でもファイルを回復することはできません。オフラインバックアップから復元する必要があります。
答え2
破損したtarファイルを生成する方法について何も表示できませんか？
ウェブサイトでバックアップしたものと言いますが、表示している問題はすべて復元/抽出時に発生する問題なので（ソース）でトラブルシューティングが必要です。
バックアップを別のコンピュータ/場所に移動した後にファイルを解凍できない場合は、ファイルが誤って作成されたか、転送中に破損している可能性があります。
エラーの原因を見つけるには：
- ネットワークサーバーで手動でバックアップを作成する（含める
pvと除く-i） - ネットワークサーバーで手動でバックアップをテストする（含める
pvと除く-i）
これまで問題が見つからなかった場合:
- Webサーバーからバックアップをコピーする
- ターゲットマシンで複製されたバックアップをテストします（含める
pvと除く-i）。
これまで問題が見つからなかった場合、バックアップスクリプトは手動で作成されたかのようにアーカイブを作成しません（手動で作成するように変更する必要があるかもしれません）。
また、関連するすべてのコマンドに絶対パスを使用する必要があります。システムに不良および$PATH/または変数および侵入者がある場合は、トロイの木馬バイナリを使用している可能性があり、これは予期しない副作用を引き起こす可能性があります。$LD_LIBRARY_PATH
tarもちろん、両方のシステムがDebian以外の互換性のないバージョンも含めることができます。強制してみてください。POSIX- 両面モード。
答え3
使用中のフラグの長い形式-iはです--ignore-zeros。これがtarがファイルの破損について文句を言わない理由です。したがって、tarファイルをデバッグするには、その-iオプションを削除すると破損したファイルのリストが表示されます。
UNIXで（通常）破損したファイルを見つける2つの方法があります。私は他の質問に与えられた答えを引用します。
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で使用するとはるかに多くのコマンドがあります。
参照：破損したファイルを探す
答え4
@MattBiancoの答えに対する推論は、私が体系的に従うことです。解決するこの特別な問題。
ブロックをゼロにすることはEOFを表しますが、これはブロック要素によって異なります（デフォルトはコンパイル定数、通常20です）。 tarの--compare|は（）を使用して暗黙的に実行される--diffようです。--ignore-zeros-i
問題を引き起こす疑いpvがある追加の複雑さを考慮して、以下を確認してください。tar -ixzブロック要因に対するTar Manの影響まず削除することをお勧めします-i
それでも役に立たない場合は、次のものと交換してください。
--read-full-records --blocking-factor=300
Googleを使ってこの記事を見ているなら「tar：Nへの単一ゼロブロック」、配管せずに試してください--ignore-zeros。