☰

错误

tag-icon • tag-icon debian tar corruption
错误

如何调试这个？这个问题是这两天突然出现的。网站的所有备份均已损坏。

如果备份只是保留为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

一定有一些数据破坏了压缩。

我还尝试通过执行以下操作来检查硬盘的运行状况：

# 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）

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

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

如果到目前为止没有发现问题，则备份脚本不会像手动创建存档时那样创建存档（并且可能应该修改为手动执行的操作）。

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

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

答案3

您使用的标志-i的长形式是--ignore-zeros。这就是为什么 tar 不会抱怨文件损坏的原因。因此，如果您想调试 tar 文件，只需删除该-i选项，您就会得到损坏文件的列表。

还有另外 2 种方法可以在 UNIX 上查找损坏的文件（一般来说）。我引用另一个问题中给出的答案。

rsync 可用于复制目录，并且如果任何错误导致 rsync 终止，则能够从终止点重新启动复制。

使用 rsync 的--dry-run选项，您可以查看将复制的内容，而无需实际复制任何内容。--stats和选项--progress也很有用。 and --human-readableor-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）。焦油的--compare|--diff似乎是用--ignore-zeros( -i) 隐式执行的。

鉴于 的额外复杂性pv，我怀疑tar -i正在引起问题xz，查看焦油人对阻塞因子的影响我建议首先删除-i

然后，如果这没有帮助，请替换为：

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

如果你只是在谷歌搜索后阅读这篇文章“tar：N 处的一个单独的零块”，并且不进行任何管道操作，然后尝试--ignore-zeros。

相关内容