如何调试呢？最近几天，这个问题突然出现了。网站的所有备份均已损坏。

如果备份仅保留为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）。

您的文件已被截断或损坏，因此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抱怨，则操作系统未检测到任何损坏，但文件仍然无效（已损坏或被截断）。无论哪种方式，您都将无法恢复此文件。您需要从离线备份中找回它。

我没有提到如何创建损坏的tar文件？

您说它是从Web站点备份的，但是所显示的问题仅是在还原/解压缩时出现的，因此（源）是您进行故障排除工作的地方。

如果在将备份移至另一台计算机/位置后无法解压缩文件，则必须将其创建错误或传输中断。

要找到错误源：

• 在Web服务器上手动创建备份（不带pv和不带-i）
• 在Web服务器上手动测试备份（不带pv和不带-i）

如果到目前为止没有发现问题：

• 从Web服务器复制备份
• 在目标计算机上测试复制的备份（不带pv和不带-i）

如果到目前为止没有发现问题，则备份脚本不会以与手动执行时相同的方式创建存档（可能应进行​​修改以手动执行操作）。

另外，请确保使用所有相关命令的绝对路径。如果您的系统中存在错误$PATH和/或$LD_LIBRARY_PATH变量，并且有入侵者，则您可能正在使用木马二进制文件，这可能会导致意外的副作用。

当然，也可能tar涉及不兼容的版本，除非两个系统都是debian。您可以尝试在两侧强制使用POSIX -mode。

您正在使用的标志-i形式是--ignore-zeros。这就是为什么tar不会抱怨已损坏的文件。因此，如果要调试tar文件，只需删除该-i选项，即可获取损坏文件的列表。

通常，还有两种其他方法可以在UNIX上查找损坏的文件。我引用另一个问题的答案。

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，但是我已经在Macs上使用过它，因此我知道它肯定可用。

要快速检查是否可以读取子目录中的文件，可以使用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：N处的零零块”而没有阅读任何内容，请尝试--ignore-zeros。