大文件分片传输后合并时出现gzip错误的解决方法咨询

看起来你在传输60GB的大压缩文件时遇到了分片合并报错的问题，我来帮你梳理下可能的原因和对应的解决步骤：

第一步：先排查本地分片的完整性 #

首先要确认是不是分片本身在切割的时候就出了问题，毕竟如果本地的分片都有问题，传到服务器合并肯定会报错：

• 在本地执行合并测试：zcat xa* > test_merged.gz，如果这一步也出现同样的unexpected end of file错误，说明分片切割过程有异常。
• 检查原文件和本地合并后的文件哈希是否一致：
  1. 先算原文件的哈希：md5sum filename.gz
  2. 再算本地合并后文件的哈希：md5sum test_merged.gz
     如果哈希不一致，那大概率是split命令执行过程中出了问题——比如后台运行的nohup split有没有因为磁盘空间不足、进程意外终止等情况中断？可以查看nohup.out日志文件里有没有报错信息，重新执行分片命令即可。

第二步：验证传输到云端的分片是否损坏 #

如果本地合并完全正常，那问题肯定出在传输环节，某个分片在scp过程中丢包或者损坏了：

• 生成本地分片的校验列表：在本地执行md5sum xa* > local_sha_checks.txt，这个文件会记录每个分片的文件名和对应的md5哈希值。
• 把local_sha_checks.txt传到云服务器的同一个目录下，然后执行md5sum -c local_sha_checks.txt，这个命令会自动比对每个分片的哈希，找出损坏的那个分片，只需要重新传输损坏的分片即可，不用全部重传。

第三步：换用更可靠的传输工具 #

scp虽然简单，但在传输大文件时遇到中断需要从头开始，而且没有自动校验机制，建议换成rsync，它支持断点续传和自动校验：

• 传输命令示例：rsync -avzP -i .pem xa* user@hostname:/path
  其中-P参数会显示传输进度并支持断点续传，-z会压缩传输数据（如果你的文件已经是gz压缩的，这个效果有限，但聊胜于无），传输完成后会自动校验文件完整性。

合并时的小技巧 #

合并的时候可以先直接拼接分片，再校验完整性，这样更容易定位问题：

• 先拼接分片：cat xa* > merged_file.gz
• 再校验压缩文件的有效性：gzip -t merged_file.gz
  如果校验通过，再用zcat merged_file.gz解压就不会有问题了；如果校验失败，再回到前面的步骤排查分片问题。

备注：内容来源于stack exchange，提问作者prudhvi