尧图网页设计 
1. 深夜的 tar 解压失败现场我先做了什么而不是慌什么1.1 报错现场的三种常见形态做运维和开发这些年tar 解压报错的场面见过太多了。尤其是那种从外网拉回来的几十 GB 数据包在深夜加到一半突然砸过来一串警告心情直接从待会就能跑模型了跌到完蛋这周又交代了。比较典型的报错有以下几类我按出现频率排个序gzip: stdin: unexpected end of file——文件被截断流没走完就没了。tar: Unexpected EOF in archive——同样是文件不完整tar 读到了不该结束的位置。tar: Error is not recoverable: exiting now——这是最让人崩溃的tar 自己判断救不回来直接退出。gzip: stdin: invalid compressed>file mysql-backup.tar.gz正常的输出应该是mysql-backup.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 4294967296但如果它输出的是mysql-backup.tar.gz: HTML document text那你就别费劲了这压根不是压缩包是下载到了某个错误页面。常见场景是你用 wget 拉一个需要登录或带防盗链的地址服务器返回了 403 页面但文件名还是.tar.gz。还有的 CDN 会返回一个 xml 格式的错误说明file同样能识别出来。接着看大小ls -lh mysql-backup.tar.gz如果你下载时有源文件的预期大小直接对比。最典型的场景是明明服务器上写着 3.2 GB本地却只有 2.1 GB那必然是中途断了。这时候gzip会以unexpected end of file的方式告诉你tarball 没写完。如果file显示正常、大小也对得上才轮到gzip -t这种专门测完整性的工具上场。这步的逻辑很简单先用最廉价的手段排除文件根本不是 tar和文件尺寸不完整两类低级问题再往深了查。1.3 为什么直接重新下载不一定对我见过不少人一看到解压报错就删文件重新拉结果拉到第三遍还是一样。原因很简单如果损坏发生在源站你重新下载 N 次损坏的字节还是在那里的。尤其是从一些不太规范的内部存储、旧硬盘上拷贝出来的归档包源文件本身就是坏的。另外有一种情况特别容易骗人你用某网盘下载到一个 tar 包看着大小没毛病但解压到一半就是报 CRC 错误。这就是文件尺寸正常但内容损坏的典型大概率是存储介质出了错或者下载工具在写入磁盘的过程中出现了静默错误。这时候你怎么重下载都没用除非换下载方式或者去源站重新打包生成一份。所以在动辄几个 GB 的文件面前重下载应该是最万不得已的方案而不是第一个方案。磨刀不误砍柴工先把报错看懂再决定下一步。2. 读懂 tar 和 gzip 的遗言报错背后的机制2.1 gzip 的完整性校验是怎么工作的.tar.gz 其实是两层结构gzip负责压缩一个 tar 归档流tar负责把多个文件打包成一个顺序流。所以你解压的时候实际上是 gzip 先解压出纯 tar 数据然后 tar 再去解析里面的文件边界。gzip 用的是 DEFLATE 算法它在压缩流里会周期性插入一些辅助信息其中一个关键点是每个压缩块末尾都有 CRC32 校验值。如果你下载的文件在传输过程中某个位翻转了gzip 解压到那个块的时候就能检测出来然后告诉你invalid compressed>curl -sI https://example.com/large-file.tar.gz | grep -i content-length再对比本地文件stat -c %s large-file.tar.gz如果两者不一致结论已经很清楚了。还有一种情况是下载工具本身的问题——比如某些多线程下载器对 HTTP 302 跳转处理得不好或者代理服务在中途把流掐断了都会造成下载成功但文件残缺的假象。我踩过一次很深的坑公司内部的代理会在文件传了 90% 的时候静默切断长连接wget 还会认为下载完成因为 HTTP 响应已经发出去了结果就是每次都在同一个位置报 EOF。最后是拿代理日志对比才发现。3.2 磁盘坏道与文件系统异常I/O error如果报错里面有Input/output error那问题基本不在 tar 也不在下载而在你存放文件的那块盘上。Linux 下遇到 I/O error 时应用层往往只收到一个EIO但系统内核会往dmesg里写详细的 SATA/NVMe 错误。这时候第一件事是dmesg | grep -i error看看有没有磁盘相关的报错比如ata1.00: status: { DRDY ERR }这种。如果有说明文件所在的扇区可能已经到了坏道边缘或者文件系统元数据出了问题。验证的方式也很简单把文件复制到另一块磁盘上再在那边解压。如果能正常解压说明是盘的问题文件本身的数据其实还是完整的只是某些扇区读取不稳定。如果复制过程本身就报 I/O error那就说明数据已经受损得考虑用ddrescue这类工具去抢救了这个我在下一章细讲。还有一种容易被忽略的场景磁盘满。文件写入过程中磁盘满了写入操作会失败但ls -lh看到的文件大小可能是一个比预期略小但看起来还行的数字。如果解压时报unexpected end of file而你的/所在分区又显示df -h用了 100%那基本就是它。3.3 源站文件本身就是残的这种属于重下载也没用的情况。判断方法其实很简单在你下载的同一台机器上从源站拿一个同文件的校验和。很多开源项目会在下载页旁边给一个SHA256SUMS文件你本地算一下sha256sum large-file.tar.gz然后把得到的哈希值和源站公布的对比。对不上那源站文件要么和官方不是同一个文件要么官方给你的这个本来就有问题。还有一种更隐蔽的情况源站文件是好的但你在 FTP、HTTP 或网盘之间中转的时候中转服务器把它写坏了。比如你从服务器 A 推到内网存储 B再从 B 下载B 底层存储如果是早年配置不高的 NAS在静默校验方面可能做得不到位。这时候你下载到的那份已经坏了重下还是坏得换路径重新从 A 取。我处理过一次云主机快照导出的 tar 包就是从对象存储拉三回坏三回最后让机房直接把 SCP 流串过来才拿到干净的文件。3.4 拷贝与挂载的隐藏坑这块特别适合那些经常和老系统打交道的人你用优盘从一台老机器拷贝 tar 包拷到一半手动拔了盘或者 Windows 下没安全弹出U 盘的 FAT32 文件系统会给你一个大小正常但尾部全是垃圾的文件。这种情况下file可能还能识别成 gzip但解压就是错。还有一个隐藏坑是文件系统的稀疏文件sparse file。如果你用cp拷贝一个稀疏文件时没有处理 --sparse 属性或者传输工具不支持稀疏文件那么膨胀后的文件里全是空洞0x00tar 读到那个位置时头部校验失败就会一直Skipping to next header。这种文件大小看着完全正常但内容静默坏了。挂载方面如果你用 NFS 或者 CIFS 挂载远程目录然后在挂载目录里直接解压 tar网络文件系统自身的不稳定也会导致 tar 读数据读到一半报Input/output error或者read error。这类问题有一个很灵验的测试动作把文件先cp到本地磁盘再本地解压。本地没问题那就是网络文件系统在作妖。4. 抢救实操能救一点是一点4.1 损坏但可读--ignore-failed-read 的边界confront tar 解压报错时如果你的 tarball 只是很少一部分损坏其他文件还完好完全可以直接放弃损坏的那几个把能救的救出来。tar 有一个参数叫--ignore-failed-read它的作用是让 tar 在遇到读错误比如某个文件数据损坏、头部校验失败时不直接放弃整个解压过程而是尽量跳过继续。用法tar --ignore-failed-read -xzf archive.tar.gz -C /dest需要说明的是这个参数对头部完全损坏以至于 tar 找不到下一个文件边界的情况帮助有限。tar 的头部块是连续排列的如果中间某个 header 坏了tar 唯一能做的就是在当前块附近找下一个合法 header找不到就只能退。而在实际中文件数据内部损坏不是 header 损坏时这个参数效果最好——因为 tar 知道每个文件的长度数据区坏了顶多影响一个文件它可以读完该文件后就跳到下一个头部。补充一个实用小技巧如果你不在乎报错只想尽量把文件解出来可以配合--warningno-unknown-keyword屏蔽一部分无关警告输出会清爽很多方便你盯着真正关键的报错tar --ignore-failed-read --warningno-unknown-keyword -xzf archive.tar.gz -C /dest但归根结底--ignore-failed-read不是修复工具它只是让 tar 更宽容。真正救不回来的文件它还是会丢的。所以解压完以后建议去目标目录里数一下文件和源清单是否一致后续缺什么再单独补齐。4.2 gzip 流中断后的分段抢救如果损坏发生在 gzip 层——也就是常见的unexpected end of file——那么情况比 tar 层损坏更麻烦一点。因为 gzip 是流式压缩一个文件解出来是一连串连续的字节流中间某个地方断了后面所有数据就全断了不像 tar 那样还能跳到下一个 header。但也不是完全没救。如果你手头有源站的分段下载能力或者你用了 aria2 这种多连接下载器之前下载时产物可能有.aria2控制文件。这时候重新执行一遍同样的下载命令aria2 会基于控制文件对你已经下载的部分做校验整合能省不少带宽。命令还是那条aria2c -c -x 16 -s 16 https://example.com/large-file.tar.gz-c是续传-x和-s是每个服务器的连接数和切分数。实测下来对于下载到一半断掉的场景aria2 的续传成功率比 wget-c要高。wget 的-c续传在服务端不支持 Range 请求时直接失效而 aria2 遇到不支持 Range 的站点会退化为普通下载不会再留下一个看似完整实则缺尾的文件。如果你的文件是从本地磁盘拷贝时损坏的没有远程源可以续传那就只能在 gzip 流量上想办法了。利用 gzip 的块结构有一些工具比如pigz配合特殊参数或者专门的gzip-recover脚本可以尝试把完整块先解出来。但这些工具的使用门槛比较高效果也不稳定我个人只建议在文件极其重要且已经再也拿不到原始文件的时候去折腾。4.3 I/O 错误与 ddrescue 的恢复流程当问题出在磁盘本身你需要的是ddrescue。它和普通dd不一样的地方在于ddrescue 专门为尽量读出更多数据设计遇到坏扇区不会直接退出而是把坏区域记下来继续往后面读还可以多轮重试。恢复流程大概是找一个足够大的目标磁盘或文件空间要大于源文件体积。执行一次基本镜像ddrescue /dev/sdb1 /mnt/recovery/disk.img /mnt/recovery/rescue.log第一次跑完后再跑几轮尝试读取之前失败的区域ddrescue -r 3 /dev/sdb1 /mnt/recovery/disk.img /mnt/recovery/rescue.log等镜像做完再用losetup挂载镜像把里面的 tar 包复制出来解压。这套流程比较底层需要你确定损坏文件具体在哪个分区。如果不确定可以用df先看路径挂在哪个设备上比如/dev/nvme0n1p2这种。ddrescue 恢复的是整个分区的镜像后续找文件用文件系统工具或者直接挂载镜像都行。如果你只需要恢复单个已被 I/O error 锁定的文件也可以更轻量重新触发内核去读它。一个常见的土办法是先sync再重新cp一次那个文件。内核有时会因为瞬时性的设备通信错误而返回 EIO但文件本身的数据还在盘上二次访问反而就正常了。当然如果每次读同一个位置都报错那真的是坏道只能走 ddrescue 的路线。4.4 重新获取断点续传与多线程下载能重下就尽量重下这句话我其实并不反对。但重下要有重下的姿势别再拿 wget 一根线去拉大文件。先说我日常用得最多的组合curl或者wget的断点续传加aria2的多线程兜底。如果你知道文件服务器的具体地址且服务器支持 Range 请求现在 HTTP 服务器基本都默认支持那wget -c就够了wget -c https://example.com/large-file.tar.gz-c只有在已存在文件的情况下才生效它会尝试从服务器上获取当前文件长度然后从断点继续写。如果你之前下载的残缺文件和源文件长度不一致wget 会重新从 0 开始这是正常行为不是 bug。想更快一点就上 aria2aria2c -x 16 -s 16 -c file.tar.gz.torrent有时候下载源有对应的种子文件BT 协议天然做完整性校验非常适合大文件分发。如果你能从源站同时拿到 HTTP 直链和种子那用 BT 基本可以保证文件完整——BitTorrent 的 piece 校验机制会逐块验证数据坏一块就重新拉这一块绝对不会出现下载完成但文件损坏的尴尬。还有一个容易被忽略的操作下载完之后第一时间记录并核对校验和。来源站的SHA256SUMS是什么本地算出来是什么一致再解压不一致就直接排查。这个小习惯能让你彻底告别解压到一半崩溃的被动局面。5. 让解压报错从偶发变成罕见日常预防清单5.1 校验和习惯一分钟就能省下几小时我强烈建议把下载完先校验练成肌肉记忆。在命令行里加一步其实只要几秒钟wget https://example.com/large-file.tar.gz https://example.com/SHA256SUMS sha256sum -c SHA256SUMSsha256sum -c会自动比对文件列表里的哈希和本地文件输出 OK 或 FAILED。如果源站没提供校验文件你可以直接去源站页面或者 GitHub Release 页面复制它的 SHA256 值手动比对。GitHub Release 每个资产旁边都有一个 SHASUMS 链接这个习惯在搞开源项目部署时特别有用能直接避免机器上解压报错结果排查半天发现是下载缓存被骗了的情况。另一种做法是把校验和嵌入到自动化脚本里。比如写一个简单的部署脚本拉包前先算哈希再决定要不要继续if echo expected-hash ./large-file.tar.gz | sha256sum -c -; then echo checksum ok, extracting... tar -xzf large-file.tar.gz else echo checksum mismatch, abort exit 1 fi这个思路在做 CI/CD 流水线、Docker 镜像构建时也很实用。Dockerfile 里的ADD指令如果远程 URL 的文件损坏构建会直接失败但报错信息往往不够直观。在构建前用 RUN 脚本做一次校验失败后还能输出日志排查体验完全不同。5.2 大文件的可靠传输工具日常传输大文件的话我建议按场景分三类本机到本机、局域网内优先用 rsync。rsync 自带校验如果传输中数据不一致它会重新同步。命令示例rsync -avP --checksum userremote:/data/large-file.tar.gz .-P等于--partial --progress意味着中断后不会删除已传部分下次继续时会基于已有文件做增量同步。--checksum会让 rsync 用文件内容算哈希来决定要不要重传而不是只看修改时间和大小——对大文件来说更保险。公网 HTTP/HTTPS优先 aria2多线程加续传前面的例子已经说过了。如果是几 GB 级别的甚至可以配合代理链路加速。文件不大但网络不稳时直接 curl 的重试参数也很管用curl -L --retry 5 --retry-delay 3 -o large-file.tar.gz https://example.com/large-file.tar.gz对象存储/OBS/S3直接用对应的 CLI 工具比如s3cmd、ossutil、rclone。这些工具内部都实现了分块上传/下载和校验比裸wget靠谱得多。有一个特别值得推荐的习惯传文件时尽量附带上.md5或者.sha256文件。有时候你发一个 5 GB 的 tar 包给同事对方解压后报unexpected end of file你第一反应是我这没问题啊然后两个人开始拉扯。如果当初顺手生成一个SHA256SUMS附带发过去对方拉下来先校验谁的文件坏了立刻就知道。这个习惯能省掉无数沟通成本。5.3 备份时的压缩策略会解压报错很多时候根源在打包时就没打干净。打包时有两个点需要特别注意第一打包前确认源目录的完整性。源码编译产物、数据库导出目录这种经常处于正在写状态的东西直接 tar 很可能把半截文件打进去。你解压的时候自然遇到 EOF——不是 tar 的问题是打包时文件本来就没写完。生产环境做备份尤其要注意这一点最好先停写、再打包或者用flock锁住关键服务。第二大目录建议分卷压缩。一条命令把整个 500 GB 目录打成一个 tar.gz 看起来省事但一旦中间任何一个环节出错整个归档全废。分卷之后至少能把损失控制在一个卷内tar czf - /var/lib/data | split -b 4G ->cat> tar解压报错排查指南：从gzip校验到数据恢复
1. 深夜的 tar 解压失败现场我先做了什么而不是慌什么1.1 报错现场的三种常见形态做运维和开发这些年tar 解压报错的场面见过太多了。尤其是那种从外网拉回来的几十 GB 数据包在深夜加到一半突然砸过来一串警告心情直接从待会就能跑模型了跌到完蛋这周又交代了。比较典型的报错有以下几类我按出现频率排个序gzip: stdin: unexpected end of file——文件被截断流没走完就没了。tar: Unexpected EOF in archive——同样是文件不完整tar 读到了不该结束的位置。tar: Error is not recoverable: exiting now——这是最让人崩溃的tar 自己判断救不回来直接退出。gzip: stdin: invalid compressed>file mysql-backup.tar.gz正常的输出应该是mysql-backup.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 4294967296但如果它输出的是mysql-backup.tar.gz: HTML document text那你就别费劲了这压根不是压缩包是下载到了某个错误页面。常见场景是你用 wget 拉一个需要登录或带防盗链的地址服务器返回了 403 页面但文件名还是.tar.gz。还有的 CDN 会返回一个 xml 格式的错误说明file同样能识别出来。接着看大小ls -lh mysql-backup.tar.gz如果你下载时有源文件的预期大小直接对比。最典型的场景是明明服务器上写着 3.2 GB本地却只有 2.1 GB那必然是中途断了。这时候gzip会以unexpected end of file的方式告诉你tarball 没写完。如果file显示正常、大小也对得上才轮到gzip -t这种专门测完整性的工具上场。这步的逻辑很简单先用最廉价的手段排除文件根本不是 tar和文件尺寸不完整两类低级问题再往深了查。1.3 为什么直接重新下载不一定对我见过不少人一看到解压报错就删文件重新拉结果拉到第三遍还是一样。原因很简单如果损坏发生在源站你重新下载 N 次损坏的字节还是在那里的。尤其是从一些不太规范的内部存储、旧硬盘上拷贝出来的归档包源文件本身就是坏的。另外有一种情况特别容易骗人你用某网盘下载到一个 tar 包看着大小没毛病但解压到一半就是报 CRC 错误。这就是文件尺寸正常但内容损坏的典型大概率是存储介质出了错或者下载工具在写入磁盘的过程中出现了静默错误。这时候你怎么重下载都没用除非换下载方式或者去源站重新打包生成一份。所以在动辄几个 GB 的文件面前重下载应该是最万不得已的方案而不是第一个方案。磨刀不误砍柴工先把报错看懂再决定下一步。2. 读懂 tar 和 gzip 的遗言报错背后的机制2.1 gzip 的完整性校验是怎么工作的.tar.gz 其实是两层结构gzip负责压缩一个 tar 归档流tar负责把多个文件打包成一个顺序流。所以你解压的时候实际上是 gzip 先解压出纯 tar 数据然后 tar 再去解析里面的文件边界。gzip 用的是 DEFLATE 算法它在压缩流里会周期性插入一些辅助信息其中一个关键点是每个压缩块末尾都有 CRC32 校验值。如果你下载的文件在传输过程中某个位翻转了gzip 解压到那个块的时候就能检测出来然后告诉你invalid compressed>curl -sI https://example.com/large-file.tar.gz | grep -i content-length再对比本地文件stat -c %s large-file.tar.gz如果两者不一致结论已经很清楚了。还有一种情况是下载工具本身的问题——比如某些多线程下载器对 HTTP 302 跳转处理得不好或者代理服务在中途把流掐断了都会造成下载成功但文件残缺的假象。我踩过一次很深的坑公司内部的代理会在文件传了 90% 的时候静默切断长连接wget 还会认为下载完成因为 HTTP 响应已经发出去了结果就是每次都在同一个位置报 EOF。最后是拿代理日志对比才发现。3.2 磁盘坏道与文件系统异常I/O error如果报错里面有Input/output error那问题基本不在 tar 也不在下载而在你存放文件的那块盘上。Linux 下遇到 I/O error 时应用层往往只收到一个EIO但系统内核会往dmesg里写详细的 SATA/NVMe 错误。这时候第一件事是dmesg | grep -i error看看有没有磁盘相关的报错比如ata1.00: status: { DRDY ERR }这种。如果有说明文件所在的扇区可能已经到了坏道边缘或者文件系统元数据出了问题。验证的方式也很简单把文件复制到另一块磁盘上再在那边解压。如果能正常解压说明是盘的问题文件本身的数据其实还是完整的只是某些扇区读取不稳定。如果复制过程本身就报 I/O error那就说明数据已经受损得考虑用ddrescue这类工具去抢救了这个我在下一章细讲。还有一种容易被忽略的场景磁盘满。文件写入过程中磁盘满了写入操作会失败但ls -lh看到的文件大小可能是一个比预期略小但看起来还行的数字。如果解压时报unexpected end of file而你的/所在分区又显示df -h用了 100%那基本就是它。3.3 源站文件本身就是残的这种属于重下载也没用的情况。判断方法其实很简单在你下载的同一台机器上从源站拿一个同文件的校验和。很多开源项目会在下载页旁边给一个SHA256SUMS文件你本地算一下sha256sum large-file.tar.gz然后把得到的哈希值和源站公布的对比。对不上那源站文件要么和官方不是同一个文件要么官方给你的这个本来就有问题。还有一种更隐蔽的情况源站文件是好的但你在 FTP、HTTP 或网盘之间中转的时候中转服务器把它写坏了。比如你从服务器 A 推到内网存储 B再从 B 下载B 底层存储如果是早年配置不高的 NAS在静默校验方面可能做得不到位。这时候你下载到的那份已经坏了重下还是坏得换路径重新从 A 取。我处理过一次云主机快照导出的 tar 包就是从对象存储拉三回坏三回最后让机房直接把 SCP 流串过来才拿到干净的文件。3.4 拷贝与挂载的隐藏坑这块特别适合那些经常和老系统打交道的人你用优盘从一台老机器拷贝 tar 包拷到一半手动拔了盘或者 Windows 下没安全弹出U 盘的 FAT32 文件系统会给你一个大小正常但尾部全是垃圾的文件。这种情况下file可能还能识别成 gzip但解压就是错。还有一个隐藏坑是文件系统的稀疏文件sparse file。如果你用cp拷贝一个稀疏文件时没有处理 --sparse 属性或者传输工具不支持稀疏文件那么膨胀后的文件里全是空洞0x00tar 读到那个位置时头部校验失败就会一直Skipping to next header。这种文件大小看着完全正常但内容静默坏了。挂载方面如果你用 NFS 或者 CIFS 挂载远程目录然后在挂载目录里直接解压 tar网络文件系统自身的不稳定也会导致 tar 读数据读到一半报Input/output error或者read error。这类问题有一个很灵验的测试动作把文件先cp到本地磁盘再本地解压。本地没问题那就是网络文件系统在作妖。4. 抢救实操能救一点是一点4.1 损坏但可读--ignore-failed-read 的边界confront tar 解压报错时如果你的 tarball 只是很少一部分损坏其他文件还完好完全可以直接放弃损坏的那几个把能救的救出来。tar 有一个参数叫--ignore-failed-read它的作用是让 tar 在遇到读错误比如某个文件数据损坏、头部校验失败时不直接放弃整个解压过程而是尽量跳过继续。用法tar --ignore-failed-read -xzf archive.tar.gz -C /dest需要说明的是这个参数对头部完全损坏以至于 tar 找不到下一个文件边界的情况帮助有限。tar 的头部块是连续排列的如果中间某个 header 坏了tar 唯一能做的就是在当前块附近找下一个合法 header找不到就只能退。而在实际中文件数据内部损坏不是 header 损坏时这个参数效果最好——因为 tar 知道每个文件的长度数据区坏了顶多影响一个文件它可以读完该文件后就跳到下一个头部。补充一个实用小技巧如果你不在乎报错只想尽量把文件解出来可以配合--warningno-unknown-keyword屏蔽一部分无关警告输出会清爽很多方便你盯着真正关键的报错tar --ignore-failed-read --warningno-unknown-keyword -xzf archive.tar.gz -C /dest但归根结底--ignore-failed-read不是修复工具它只是让 tar 更宽容。真正救不回来的文件它还是会丢的。所以解压完以后建议去目标目录里数一下文件和源清单是否一致后续缺什么再单独补齐。4.2 gzip 流中断后的分段抢救如果损坏发生在 gzip 层——也就是常见的unexpected end of file——那么情况比 tar 层损坏更麻烦一点。因为 gzip 是流式压缩一个文件解出来是一连串连续的字节流中间某个地方断了后面所有数据就全断了不像 tar 那样还能跳到下一个 header。但也不是完全没救。如果你手头有源站的分段下载能力或者你用了 aria2 这种多连接下载器之前下载时产物可能有.aria2控制文件。这时候重新执行一遍同样的下载命令aria2 会基于控制文件对你已经下载的部分做校验整合能省不少带宽。命令还是那条aria2c -c -x 16 -s 16 https://example.com/large-file.tar.gz-c是续传-x和-s是每个服务器的连接数和切分数。实测下来对于下载到一半断掉的场景aria2 的续传成功率比 wget-c要高。wget 的-c续传在服务端不支持 Range 请求时直接失效而 aria2 遇到不支持 Range 的站点会退化为普通下载不会再留下一个看似完整实则缺尾的文件。如果你的文件是从本地磁盘拷贝时损坏的没有远程源可以续传那就只能在 gzip 流量上想办法了。利用 gzip 的块结构有一些工具比如pigz配合特殊参数或者专门的gzip-recover脚本可以尝试把完整块先解出来。但这些工具的使用门槛比较高效果也不稳定我个人只建议在文件极其重要且已经再也拿不到原始文件的时候去折腾。4.3 I/O 错误与 ddrescue 的恢复流程当问题出在磁盘本身你需要的是ddrescue。它和普通dd不一样的地方在于ddrescue 专门为尽量读出更多数据设计遇到坏扇区不会直接退出而是把坏区域记下来继续往后面读还可以多轮重试。恢复流程大概是找一个足够大的目标磁盘或文件空间要大于源文件体积。执行一次基本镜像ddrescue /dev/sdb1 /mnt/recovery/disk.img /mnt/recovery/rescue.log第一次跑完后再跑几轮尝试读取之前失败的区域ddrescue -r 3 /dev/sdb1 /mnt/recovery/disk.img /mnt/recovery/rescue.log等镜像做完再用losetup挂载镜像把里面的 tar 包复制出来解压。这套流程比较底层需要你确定损坏文件具体在哪个分区。如果不确定可以用df先看路径挂在哪个设备上比如/dev/nvme0n1p2这种。ddrescue 恢复的是整个分区的镜像后续找文件用文件系统工具或者直接挂载镜像都行。如果你只需要恢复单个已被 I/O error 锁定的文件也可以更轻量重新触发内核去读它。一个常见的土办法是先sync再重新cp一次那个文件。内核有时会因为瞬时性的设备通信错误而返回 EIO但文件本身的数据还在盘上二次访问反而就正常了。当然如果每次读同一个位置都报错那真的是坏道只能走 ddrescue 的路线。4.4 重新获取断点续传与多线程下载能重下就尽量重下这句话我其实并不反对。但重下要有重下的姿势别再拿 wget 一根线去拉大文件。先说我日常用得最多的组合curl或者wget的断点续传加aria2的多线程兜底。如果你知道文件服务器的具体地址且服务器支持 Range 请求现在 HTTP 服务器基本都默认支持那wget -c就够了wget -c https://example.com/large-file.tar.gz-c只有在已存在文件的情况下才生效它会尝试从服务器上获取当前文件长度然后从断点继续写。如果你之前下载的残缺文件和源文件长度不一致wget 会重新从 0 开始这是正常行为不是 bug。想更快一点就上 aria2aria2c -x 16 -s 16 -c file.tar.gz.torrent有时候下载源有对应的种子文件BT 协议天然做完整性校验非常适合大文件分发。如果你能从源站同时拿到 HTTP 直链和种子那用 BT 基本可以保证文件完整——BitTorrent 的 piece 校验机制会逐块验证数据坏一块就重新拉这一块绝对不会出现下载完成但文件损坏的尴尬。还有一个容易被忽略的操作下载完之后第一时间记录并核对校验和。来源站的SHA256SUMS是什么本地算出来是什么一致再解压不一致就直接排查。这个小习惯能让你彻底告别解压到一半崩溃的被动局面。5. 让解压报错从偶发变成罕见日常预防清单5.1 校验和习惯一分钟就能省下几小时我强烈建议把下载完先校验练成肌肉记忆。在命令行里加一步其实只要几秒钟wget https://example.com/large-file.tar.gz https://example.com/SHA256SUMS sha256sum -c SHA256SUMSsha256sum -c会自动比对文件列表里的哈希和本地文件输出 OK 或 FAILED。如果源站没提供校验文件你可以直接去源站页面或者 GitHub Release 页面复制它的 SHA256 值手动比对。GitHub Release 每个资产旁边都有一个 SHASUMS 链接这个习惯在搞开源项目部署时特别有用能直接避免机器上解压报错结果排查半天发现是下载缓存被骗了的情况。另一种做法是把校验和嵌入到自动化脚本里。比如写一个简单的部署脚本拉包前先算哈希再决定要不要继续if echo expected-hash ./large-file.tar.gz | sha256sum -c -; then echo checksum ok, extracting... tar -xzf large-file.tar.gz else echo checksum mismatch, abort exit 1 fi这个思路在做 CI/CD 流水线、Docker 镜像构建时也很实用。Dockerfile 里的ADD指令如果远程 URL 的文件损坏构建会直接失败但报错信息往往不够直观。在构建前用 RUN 脚本做一次校验失败后还能输出日志排查体验完全不同。5.2 大文件的可靠传输工具日常传输大文件的话我建议按场景分三类本机到本机、局域网内优先用 rsync。rsync 自带校验如果传输中数据不一致它会重新同步。命令示例rsync -avP --checksum userremote:/data/large-file.tar.gz .-P等于--partial --progress意味着中断后不会删除已传部分下次继续时会基于已有文件做增量同步。--checksum会让 rsync 用文件内容算哈希来决定要不要重传而不是只看修改时间和大小——对大文件来说更保险。公网 HTTP/HTTPS优先 aria2多线程加续传前面的例子已经说过了。如果是几 GB 级别的甚至可以配合代理链路加速。文件不大但网络不稳时直接 curl 的重试参数也很管用curl -L --retry 5 --retry-delay 3 -o large-file.tar.gz https://example.com/large-file.tar.gz对象存储/OBS/S3直接用对应的 CLI 工具比如s3cmd、ossutil、rclone。这些工具内部都实现了分块上传/下载和校验比裸wget靠谱得多。有一个特别值得推荐的习惯传文件时尽量附带上.md5或者.sha256文件。有时候你发一个 5 GB 的 tar 包给同事对方解压后报unexpected end of file你第一反应是我这没问题啊然后两个人开始拉扯。如果当初顺手生成一个SHA256SUMS附带发过去对方拉下来先校验谁的文件坏了立刻就知道。这个习惯能省掉无数沟通成本。5.3 备份时的压缩策略会解压报错很多时候根源在打包时就没打干净。打包时有两个点需要特别注意第一打包前确认源目录的完整性。源码编译产物、数据库导出目录这种经常处于正在写状态的东西直接 tar 很可能把半截文件打进去。你解压的时候自然遇到 EOF——不是 tar 的问题是打包时文件本来就没写完。生产环境做备份尤其要注意这一点最好先停写、再打包或者用flock锁住关键服务。第二大目录建议分卷压缩。一条命令把整个 500 GB 目录打成一个 tar.gz 看起来省事但一旦中间任何一个环节出错整个归档全废。分卷之后至少能把损失控制在一个卷内tar czf - /var/lib/data | split -b 4G ->cat>