これをデバッグするにはどうすればいいですか? この問題はここ数日で突然発生しました。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? これまではそんなことは一度もありませんでした。一部のファイルに何かひどい間違いがあります。
ディレクトリには約 15,000 個の 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)。
答え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警告のみが表示される場合、OS は破損を検出していませんが、ファイルは無効です (破損しているか切り捨てられています)。いずれにしても、このファイルを回復することはできません。オフライン バックアップからファイルを取り戻す必要があります。
答え2
壊れた tar ファイルがどのように作成されるかについては何も言及されていないようです。
Web サイトからのバックアップだと言っていますが、表示されている問題はすべて復元/解凍時に発生するため、トラブルシューティングの作業はそこ (ソース) で行う必要があります。
バックアップを別のマシン/場所に移動した後でファイルを解凍できない場合は、ファイルの作成に誤りがあったか、転送中に破損した可能性があります。
エラーの原因を特定するには:
- ウェブサーバーに手動でバックアップを作成する（ なし
pvと なし-i） - ウェブサーバー上でバックアップを手動でテストする（ なし
pvと なし-i）
今のところ問題が見つからなかった場合:
- ウェブサーバーからバックアップをコピーする
- コピーしたバックアップをターゲットマシンでテストする（なし
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/
rsync が Mac OS X にデフォルトでインストールされているかどうかはわかりませんが、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ブロッキングファクターのタールマンまず削除することをお勧めします-i
それでも問題が解決しない場合は、次のように置き換えます。
--read-full-records --blocking-factor=300
もしあなたがグーグルで調べてこれを読んでいるなら「tar: N に 1 つのゼロ ブロック」、何もパイプしていない場合は、 を試してください--ignore-zeros。