web-dev-qa-db-ja.com

デバッグ方法：tar：単一のゼロブロック

これをデバッグする方法は？この問題は、過去数日以内に突然現れました。 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）。

debiantarcorruption
8
clarkk

ファイルが切り捨てられているか破損しているため、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は破損を検出しませんでしたが、それでもファイルは無効です（破損または切り捨て）。いずれにしても、このファイルを回復することはできません。オフラインバックアップからそれを取り戻す必要があります。

7
Gilles 'SO- stop being evil'

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

Webサイトからのバックアップだとおっしゃっていますが、表示されている問題はすべて復元/解凍時に発生するため、トラブルシューティングに必要な場所（ソース）があります。

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

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

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

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

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

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

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

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

1
MattBianco

@MattBiancoによる回答の推論の行は、この特定の問題をsolveするために体系的に従うものです。

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

pvの余分な複雑さを考えると、tar -iがxzに問題を引き起こしているのではないかと思います ブロッキングファクターに関するtar man 最初に-iを削除することをお勧めします

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

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

Googled "tar：Nにある唯一のゼロブロック"を読んでいて、何もパイプしていない場合は、--ignore-zerosを試してください。

0
earcam

長い形式で-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で使用するとさらに多くのコマンドが使用できます。

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

0
tmow