干运维和开发这行谁还没被“大文件”折腾过几百 GB 的数据库备份、训练数据集、视频素材、日志压缩包每次要跨服务器传输、拷到移动硬盘、或者发给同事总会遇到各种尴尬时刻邮件附件限制 2GB、某个文件中转平台限制 4GB、老移动硬盘还是 FAT32 格式单文件不能超过 4GB、SCP 传到一半网络断了又要从头来……这些情况靠“大文件切割与合并”这套 Linux 基本功都能化解。把一个大块头拆成能塞进各种“瓶颈”的小分片传完再拼回去顺带做一次完整性校验整个过程干净利落。这篇文章我会把切割工具选型、split 参数细节、合并与校验、tar/dd 进阶玩法、常见排错整个链路讲一遍还会附带不少我在实际项目里总结的踩坑经验适合所有需要在 Linux 服务器上搬运大文件的同学参考。内容不复杂但细节很多建议收藏后照着试一遍。1. 大文件切割的核心场景与选型1.1 逼你动手切文件的几个典型场景先别急着敲命令想清楚“为什么要切”比“怎么切”更重要。这几年我遇到的大文件切割需求基本逃不出下面几类。文件系统限制是最常见的原因。FAT32 格式的老移动硬盘、行车记录仪内存卡、部分相机存储卡单文件最大只能到 4GB。你辛辛苦苦做好的虚拟机镜像、磁盘备份往这些设备上一拷就报“文件太大”这时候只能先切分。哪怕现在 NTFS 和 exFAT 已经很普及公司里仍有一堆老设备、老系统不认新格式切分反而是最省事的办法。传输平台限制也很普遍。邮件附件、企业 IM 文件传输、网盘上传、自建的中转站几乎每个平台都有单文件上限。有的是 1GB有的是 5GB规则五花八门。把文件切成多个小分片逐个上传到了目的地再合并就能绕开这些限制。第三个场景是网络不稳定导致的大文件传输失败。我曾经在跨地域专线上传一个 80GB 的数据库备份SCP 跑到 70% 断线整个文件作废重来。后来我固定习惯凡是超过几个 GB 的文件一律先切成 500MB 或 1GB 的分片再传。哪片传失败就补哪片效率提升非常明显。再就是备份归档。把一个大目录拆成多卷分散放到多张光盘、多个 U 盘或者不同服务器上这时候分卷功能就派上用场了。tar 配合 split 可以做到“打包的同时分卷”后面我会专门讲。1.2 工具选型谁适合哪个场景Linux 下跟文件切割合并相关的工具不少但它们各有侧重点选错工具往往事倍功半。我整理了一张对照表基本涵盖了我日常工作里会用到的组合。工具适合场景关键特性split按固定大小快速切分普通文件支持按大小、行数、总块数切分速度快cat合并 split 产生的分片字节级拼接支持通配符和标准输入输出dd精确字节级切割、磁盘镜像偏移读写skip/count 可按块偏移底层操作tar目录打包 分卷归档可与 split/管道组合支持压缩流md5sum / sha256sum合并后的完整性校验哈希对比确认文件没有损坏如果你只是想把一个大文件“切小再拼回去”首选 split 加 cat简单直接内存占用极低。dd 强在按偏移量精确读一块比如从磁盘镜像里抢救某个区域的数据这种场景 split 做不到。tar 强在能把整个目录树做成流再交给 split 分卷相当于把“打包”和“切割”合并成一步。md5sum 虽然不是切割工具但它是我每次合并完必须做的一步没有校验的合并等于裸奔。从使用频率来看split 和 cat 占了 80% 以上的场景所以下面的内容我会重点展开。2. split 快速切割参数、实测与细节2.1 几个必掌握参数与单位换算坑split 命令的完整用法可以查 man但日常高频场景只需要记几个参数。-b指定分片大小比如-b 100M表示每片 100MB-d让后缀用数字而不是字母-a指定后缀长度-l按行数切割适合日志、CSV 这类文本文件-n按总块数均分适合你已经确定要切几片时使用。这里有个非常容易踩的坑单位大小写。在 GNU coreutils 里-b 1M是 1048576 字节2 的 20 次方而-b 1MB是 1000000 字节10 的 6 次方。这两个数差了 4.8%如果文件很大最后合并出来的 md5 会对不上。我一开始也吃过这个亏切一个 200GB 的文件每一片用MB为单位结果最后一片大小异常排查了半天才发现是单位混用。记住一个准则不写B后缀只用K、M、G、T这些表示的都是 1024 进制。-d -a 3是个很值得固定的组合。-d让后缀变为000、001、002这样的数字-a 3让数字位数为 3最多可以支持 1000 个分片。如果不用-dsplit 默认用字母后缀先是aa、ab……一直排下去分片多了很容易乱而且字母后缀在排序时不如数字补零直观。2.2 实操示例把 4.7GB 镜像切成 16 个 300MB 分片下面这个例子我最近刚在项目里用过。有一个 4.7GB 的服务器安装镜像需要传到某个限制单文件 500MB 的临时中转站我把它切成了 300MB 一片split -b 300M -d -a 3 app_server_2024.iso app_iso_tmp_命令执行后没有任何输出这是正常的。执行完看一下结果ls -lh app_iso_tmp_*输出大概是-rw-r--r-- 1 user user 300M 2024-01-01 10:00 app_iso_tmp_000 -rw-r--r-- 1 user user 300M 2024-01-01 10:00 app_iso_tmp_001 ... -rw-r--r-- 1 user user 300M 2024-01-01 10:00 app_iso_tmp_015整个文件 4.7GB300MB 一片理论上有 16 片多一点所以最后一片只有约 130MB。这一点不用惊慌最后一片比前面的小是正常的说明切割结束时机正好没有多余填充数据。如果你希望每一片大小完全一致就得用split -n 16按块数切但那样文件总大小会被均分成 16 份最后一片也不会特别整齐物理上很难做到所有分片完全等大还刚好覆盖原文件。如果你担心切割过程没动静可以加--verbose参数每生成一个分片都会打印一行split --verbose -b 300M -d -a 3 app_server_2024.iso app_iso_tmp_2.3 切割时的命名、路径与资源占用细节前缀命名看起来是小事但实际上很影响后续操作。我习惯用“业务名 下划线 序号”的格式比如app_log_july_这样通配符匹配时非常安全不会误伤同目录下的其他文件。如果直接用a、b这种无意义前缀合的时候很容易匹配到不相关的文件。split 是按流式方式读取源文件并写出的内存占用很低哪怕切 100GB 的文件split 自身的内存消耗也基本可以忽略。但它有一个隐藏成本磁盘 IO 是双倍的。读一遍大文件再写一遍分片相当于总共读了原文件一次、写了一个原文件大小的数据量。所以磁盘剩余空间至少要等于原文件大小最好留出 1.2 倍以上的余量。如果目标磁盘空间不够切到一半会直接报No space left on device已经生成的分片还留在磁盘上收拾起来很麻烦。另外split 默认不会删除原文件它只负责生成分片。如果你本意是切割后释放原文件空间记得手动确认分片没问题后再删除。千万不要在没校验的情况下就把原文件删了否则分片一旦出错后悔都来不及。3. 合并与完整性校验一个都不能省3.1 cat 合并的标准操作与顺序陷阱切割的下一步就是合并。合并的标准姿势很简单cat app_iso_tmp_0* app_server_2024_restored.isocat 会把app_iso_tmp_000、app_iso_tmp_001依次读出按字节拼接后写入目标文件。关键是“顺序”一定要对。app_iso_tmp_0*这个通配符由 shell 展开而 shell 默认按字典序排列。因为之前用了-d -a 3文件名是000、001直到015字典序和自然序完全一致所以合并顺序不会乱。如果你没用数字补零的方式而是生成了part_1、part_2、part_10这类名字通配符展开后顺序会变成part_1、part_10、part_2合并出来的文件就彻底错了。这种错误非常隐蔽因为它不会报错只有在解压或校验时才会暴露。对应地可以用排序后再合并的方式ls app_iso_tmp_* | sort -V | xargs cat app_server_2024_restored.isosort -V是版本号排序能把part_2排在part_10前面比较符合人对“序号”的直觉。如果你切的是文本文件而且按行切割合并后还要注意行尾有没有被破坏。但用-b按字节切不会触碰内容合并后就和原文件字节完全一致没有换行符问题。3.2 合并后必须做完整性校验合并完别急着用先做一次完整性校验。最简单的办法是对比哈希值md5sum app_server_2024.iso app_server_2024_restored.iso如果两行输出的哈希完全一致说明文件没有问题。如果不想每次都手动对比两个值也可以生成校验文件后用-c参数自动检查md5sum app_server_2024.iso checksum.md5 md5sum -c checksum.md5输出OK就是通过输出FAILED就说明有问题。在实际项目中我更推荐用 sha256sum校验机制相同但更稳妥sha256sum app_server_2024.iso app_server_2024_restored.iso校验这一步真的不能省。我见过太多人传输大文件后不校验就直接解压结果解到一半报错才发现分片顺序错了或者某个分片损坏又要重新传一遍。多花十几秒做一次哈希比对能省掉几小时的重传时间。3.3 合并时不能忽略的三个坑第一个坑是磁盘空间。合并过程中会同时存在所有分片和目标文件目标文件大小等于原文件大小所以磁盘剩余必须大于原文件大小。用df -h提前确认别等写满磁盘报错才反应过来。第二个坑是输出文件的命名。合并命令cat app_iso_tmp_0* 某个文件输出文件千万不要叫app_iso_tmp_合并之类还带前缀名字因为重定向会先把输出文件截断如果这个文件恰好又匹配了前面的通配符就会把源分片直接清空。我自己的习惯是把合并结果输出到另一个目录或者起一个完全没有关联的名字比如restored.iso。第三个坑是中断。合并是大文件读写耗时可能比较长中途按 CtrlC 会留下一个残缺的目标文件。关键是你很难判断残缺到什么程度后续检查时容易被误导。建议合并前先确认源分片都在合并过程中尽量不要中断或者干脆在脚本里加上trap处理中断时自动删除半成品文件。4. 分卷归档、dd 级切割与流式处理4.1 tar 配合 split 做目录分卷打包如果我要切割的不是单个文件而是一个大目录直接用 split 切目录是不行的因为 split 只能处理文件。标准做法是先用 tar 把目录打包成流再交给 split 分卷。打包并分卷的命令tar -czv -f - ./project_dir | split -d -b 2G - part_backup.tar.gz.这里-f -表示 tar 输出到标准输出不生成文件split 的-表示从标准输入读取。注意我用-c做了 gzip 压缩所以分片名字带有.tar.gz.前缀加数字后缀。2GB 一片适合放到大多数文件系统。恢复的时候可以直接流式合并解压cat part_backup.tar.gz.* | tar -xzv -f -也可以先合并成完整 tar 文件再解压cat part_backup.tar.gz.* full_backup.tar.gz tar -xzvf full_backup.tar.gz第一种方式的好处是不需要额外的磁盘空间存放合并后的文件直接边合并边解压非常省空间。坏处是如果解压中途出错排查起来没那么直观。第二种方式适合事后还要保留完整备份包的场景。一个常见的失败情况是解压时报gzip: stdin: not in gzip format。这通常不是 gzip 本身坏了而是分片顺序不对。检查一下分片文件名是不是part_backup.tar.gz.000、part_backup.tar.gz.001……如果命名不规则用sort -V排序后再合并。4.2 dd 精确到字节的切割与拼装split 是按顺序切分整个文件而 dd 更适合“按偏移量精确读取某一区段”。比如我有一个磁盘镜像storage.img只想取出从 100MB 处开始的 50MB 数据dd ifstorage.img ofrescue_part.bin bs1M skip100 count50 statusprogress这里的bs1M是每次读写块大小skip100表示跳过 100 个块也就是跳过 100MBcount50表示读取 50 个块即 50MB。statusprogress会显示实时进度。注意 dd 的参数含义skip和count的单位是“块”块大小由bs决定。很多人把skip100理解成“跳过 100 字节”那就差远了。如果确实需要精确到字节可以把bs1但那样读写效率会非常低大文件切分时基本不这么用。把分片写回指定位置用dd ifrescue_part.bin ofstorage_restored.img bs1M seek100seek100表示写入时跳过目标文件前 100 个块从第 101 块开始覆盖。这种方式适合在已有文件上打补丁比如修复某个偏移处的数据块。但如果你把seek用在一个不存在的文件上dd 会创建一个稀疏文件前面 100MB 内容是空洞这在某些场景下可能不是你想要的需要注意。dd 是底层命令if 和 of 写反、bs 设置错误都可能瞬间把源文件清空或者写出垃圾数据。实际使用中我建议先在测试文件上演练一遍再操作真实数据尤其是of指向的数据很重要的场景。4.3 流式传输与远端解包大文件切割和传输经常是串在一起做的。跨服务器传数据时我常用这种管道组合tar -czf - ./data | split -b 500M -d -a 3 - data_tgz_ scp data_tgz_* 远端主机:/目标目录/到了远端一条命令完成合并解压cd 目标目录 cat data_tgz_* | tar -xzf - -C ./接收目录这整个流程中本地不会出现完整的打包文件每个分片只有 500MB传输时哪个分片失败就单独补传哪个非常灵活。如果中转平台只允许单文件不超过某个大小这个方案基本能应对任何限制。配合 pv 命令还能显示传输和解包进度cat data_tgz_* | pv | tar -xzf - -C ./接收目录5. 常见问题与排查技巧实录把我在实际使用中遇到过的问题整理成了一份速查表你可以直接对照排查。问题可能原因解决方案合并后 md5/sha256 不一致分片顺序错乱、某个分片损坏、切割单位混用用 sort -V 排序合并重新比对每个分片大小和哈希split 报“输出文件后缀已用完”分片数量超过-a支持的上限增大-a如-a 4或改用更大分片大小cat 合并出来的 tar 解压报格式错误分片顺序不对或某个分片不完整用ls -l对比各分片大小用sort -V排序后重试合并时磁盘空间不足磁盘剩余小于原文件大小清理磁盘或改用流式合并解压方式传输到一半某个分片丢失网络中断、存储介质异常只补传缺失分片不需要重传整个文件用-b 100M切完文件最后一片和预期大小不符文件总大小不是分片大小的整数倍这是正常的不需要处理最后一片小于设定值即可FAT32 移动硬盘复制仍提示文件过大切分后的分片还是超过 4GB修改分片大小确保单片小于 4GB合并时通配符匹配到了多余文件前缀命名不够独特或目录里混入其他分片改用特征更明显的前缀输出文件放到独立目录下面几个场景比较典型我单独展开讲讲。第一个是分片数量超过预期。如果split -b 100M -d -a 2切一个 50GB 的文件需要 500 个分片而-a 2最多只支持 100 个数字后缀00 到 99split 会在第 101 个分片时报错。这时候不要慌已经切好的分片还在只是命名已经到达上限。解决方法是重新用-a 3或-a 4切一遍或者改用更大的分片大小。第二个是合并出来的文件能解压但内容损坏。有人合并后能正常打开压缩包但解出来的文件缺失一部分这种情况通常不是顺序错而是某个分片在传输过程中被截断或者填充了空数据。排查方法是ls -l逐一确认每个分片大小是否与切割时一致同时对每个分片做一次 md5sum和切割完成后生成的校验清单比对。我在切割完成后会顺手生成一份分片 hash 清单md5sum app_iso_tmp_* part_checksums.md5传输合并后再执行md5sum -c part_checksums.md5哪一片有问题一目了然。第三个是超大文件 hash 计算太慢。对大文件做完整 sha256 可能要几分钟有时候不想等我会上传后只对比总大小和最后一个分片的哈希作为快速边界检查。如果总大小一致、最后一个分片 hash 一致文件基本不会有问题但严谨场景还是建议做完整哈希校验。第四个是远程传输分片时ssh 会话被终端断开导致中断。推荐使用 nohup 加后台运行或者直接写脚本让分片逐个 scp失败自动重试。这个不属于切割命令本身的问题但在大文件传输场景里非常影响体验列出来供参考。6. 我这些年用下来的个人心得切文件这件事技术含量不算高但我发现很多人吃亏都吃在“切之前没想好怎么合”。命名规范、分片顺序、校验清单这三样比切分命令本身更重要。我现在的固定流程是切分前先确认目标磁盘空间用split -b 大小 -d -a 3统一命名切完立即生成一份 md5 清单传输完合并后执行md5sum -c校验全部通过才删除源文件。这套流程用顺手之后我再也没有因为大文件传输出过事故。最后分享一个小技巧split 命令本身支持--filter参数可以在切分的同时对每个分片做进一步处理比如边切边压缩。比如你想把一个大日志文件按 100MB 切完并各自压缩split -b 100M --filtergzip $FILE.gz big_log.txt part_log_这样每个分片都会生成对应的part_log_000.gz省得合并后想用的时候还要重新解压。不过这个参数在 macOS 自带的 split 里不一定支持Linux 下实测没问题。如果你主要用 Linux 服务器可以放心用。
干运维和开发这行谁还没被“大文件”折腾过几百 GB 的数据库备份、训练数据集、视频素材、日志压缩包每次要跨服务器传输、拷到移动硬盘、或者发给同事总会遇到各种尴尬时刻邮件附件限制 2GB、某个文件中转平台限制 4GB、老移动硬盘还是 FAT32 格式单文件不能超过 4GB、SCP 传到一半网络断了又要从头来……这些情况靠“大文件切割与合并”这套 Linux 基本功都能化解。把一个大块头拆成能塞进各种“瓶颈”的小分片传完再拼回去顺带做一次完整性校验整个过程干净利落。这篇文章我会把切割工具选型、split 参数细节、合并与校验、tar/dd 进阶玩法、常见排错整个链路讲一遍还会附带不少我在实际项目里总结的踩坑经验适合所有需要在 Linux 服务器上搬运大文件的同学参考。内容不复杂但细节很多建议收藏后照着试一遍。1. 大文件切割的核心场景与选型1.1 逼你动手切文件的几个典型场景先别急着敲命令想清楚“为什么要切”比“怎么切”更重要。这几年我遇到的大文件切割需求基本逃不出下面几类。文件系统限制是最常见的原因。FAT32 格式的老移动硬盘、行车记录仪内存卡、部分相机存储卡单文件最大只能到 4GB。你辛辛苦苦做好的虚拟机镜像、磁盘备份往这些设备上一拷就报“文件太大”这时候只能先切分。哪怕现在 NTFS 和 exFAT 已经很普及公司里仍有一堆老设备、老系统不认新格式切分反而是最省事的办法。传输平台限制也很普遍。邮件附件、企业 IM 文件传输、网盘上传、自建的中转站几乎每个平台都有单文件上限。有的是 1GB有的是 5GB规则五花八门。把文件切成多个小分片逐个上传到了目的地再合并就能绕开这些限制。第三个场景是网络不稳定导致的大文件传输失败。我曾经在跨地域专线上传一个 80GB 的数据库备份SCP 跑到 70% 断线整个文件作废重来。后来我固定习惯凡是超过几个 GB 的文件一律先切成 500MB 或 1GB 的分片再传。哪片传失败就补哪片效率提升非常明显。再就是备份归档。把一个大目录拆成多卷分散放到多张光盘、多个 U 盘或者不同服务器上这时候分卷功能就派上用场了。tar 配合 split 可以做到“打包的同时分卷”后面我会专门讲。1.2 工具选型谁适合哪个场景Linux 下跟文件切割合并相关的工具不少但它们各有侧重点选错工具往往事倍功半。我整理了一张对照表基本涵盖了我日常工作里会用到的组合。工具适合场景关键特性split按固定大小快速切分普通文件支持按大小、行数、总块数切分速度快cat合并 split 产生的分片字节级拼接支持通配符和标准输入输出dd精确字节级切割、磁盘镜像偏移读写skip/count 可按块偏移底层操作tar目录打包 分卷归档可与 split/管道组合支持压缩流md5sum / sha256sum合并后的完整性校验哈希对比确认文件没有损坏如果你只是想把一个大文件“切小再拼回去”首选 split 加 cat简单直接内存占用极低。dd 强在按偏移量精确读一块比如从磁盘镜像里抢救某个区域的数据这种场景 split 做不到。tar 强在能把整个目录树做成流再交给 split 分卷相当于把“打包”和“切割”合并成一步。md5sum 虽然不是切割工具但它是我每次合并完必须做的一步没有校验的合并等于裸奔。从使用频率来看split 和 cat 占了 80% 以上的场景所以下面的内容我会重点展开。2. split 快速切割参数、实测与细节2.1 几个必掌握参数与单位换算坑split 命令的完整用法可以查 man但日常高频场景只需要记几个参数。-b指定分片大小比如-b 100M表示每片 100MB-d让后缀用数字而不是字母-a指定后缀长度-l按行数切割适合日志、CSV 这类文本文件-n按总块数均分适合你已经确定要切几片时使用。这里有个非常容易踩的坑单位大小写。在 GNU coreutils 里-b 1M是 1048576 字节2 的 20 次方而-b 1MB是 1000000 字节10 的 6 次方。这两个数差了 4.8%如果文件很大最后合并出来的 md5 会对不上。我一开始也吃过这个亏切一个 200GB 的文件每一片用MB为单位结果最后一片大小异常排查了半天才发现是单位混用。记住一个准则不写B后缀只用K、M、G、T这些表示的都是 1024 进制。-d -a 3是个很值得固定的组合。-d让后缀变为000、001、002这样的数字-a 3让数字位数为 3最多可以支持 1000 个分片。如果不用-dsplit 默认用字母后缀先是aa、ab……一直排下去分片多了很容易乱而且字母后缀在排序时不如数字补零直观。2.2 实操示例把 4.7GB 镜像切成 16 个 300MB 分片下面这个例子我最近刚在项目里用过。有一个 4.7GB 的服务器安装镜像需要传到某个限制单文件 500MB 的临时中转站我把它切成了 300MB 一片split -b 300M -d -a 3 app_server_2024.iso app_iso_tmp_命令执行后没有任何输出这是正常的。执行完看一下结果ls -lh app_iso_tmp_*输出大概是-rw-r--r-- 1 user user 300M 2024-01-01 10:00 app_iso_tmp_000 -rw-r--r-- 1 user user 300M 2024-01-01 10:00 app_iso_tmp_001 ... -rw-r--r-- 1 user user 300M 2024-01-01 10:00 app_iso_tmp_015整个文件 4.7GB300MB 一片理论上有 16 片多一点所以最后一片只有约 130MB。这一点不用惊慌最后一片比前面的小是正常的说明切割结束时机正好没有多余填充数据。如果你希望每一片大小完全一致就得用split -n 16按块数切但那样文件总大小会被均分成 16 份最后一片也不会特别整齐物理上很难做到所有分片完全等大还刚好覆盖原文件。如果你担心切割过程没动静可以加--verbose参数每生成一个分片都会打印一行split --verbose -b 300M -d -a 3 app_server_2024.iso app_iso_tmp_2.3 切割时的命名、路径与资源占用细节前缀命名看起来是小事但实际上很影响后续操作。我习惯用“业务名 下划线 序号”的格式比如app_log_july_这样通配符匹配时非常安全不会误伤同目录下的其他文件。如果直接用a、b这种无意义前缀合的时候很容易匹配到不相关的文件。split 是按流式方式读取源文件并写出的内存占用很低哪怕切 100GB 的文件split 自身的内存消耗也基本可以忽略。但它有一个隐藏成本磁盘 IO 是双倍的。读一遍大文件再写一遍分片相当于总共读了原文件一次、写了一个原文件大小的数据量。所以磁盘剩余空间至少要等于原文件大小最好留出 1.2 倍以上的余量。如果目标磁盘空间不够切到一半会直接报No space left on device已经生成的分片还留在磁盘上收拾起来很麻烦。另外split 默认不会删除原文件它只负责生成分片。如果你本意是切割后释放原文件空间记得手动确认分片没问题后再删除。千万不要在没校验的情况下就把原文件删了否则分片一旦出错后悔都来不及。3. 合并与完整性校验一个都不能省3.1 cat 合并的标准操作与顺序陷阱切割的下一步就是合并。合并的标准姿势很简单cat app_iso_tmp_0* app_server_2024_restored.isocat 会把app_iso_tmp_000、app_iso_tmp_001依次读出按字节拼接后写入目标文件。关键是“顺序”一定要对。app_iso_tmp_0*这个通配符由 shell 展开而 shell 默认按字典序排列。因为之前用了-d -a 3文件名是000、001直到015字典序和自然序完全一致所以合并顺序不会乱。如果你没用数字补零的方式而是生成了part_1、part_2、part_10这类名字通配符展开后顺序会变成part_1、part_10、part_2合并出来的文件就彻底错了。这种错误非常隐蔽因为它不会报错只有在解压或校验时才会暴露。对应地可以用排序后再合并的方式ls app_iso_tmp_* | sort -V | xargs cat app_server_2024_restored.isosort -V是版本号排序能把part_2排在part_10前面比较符合人对“序号”的直觉。如果你切的是文本文件而且按行切割合并后还要注意行尾有没有被破坏。但用-b按字节切不会触碰内容合并后就和原文件字节完全一致没有换行符问题。3.2 合并后必须做完整性校验合并完别急着用先做一次完整性校验。最简单的办法是对比哈希值md5sum app_server_2024.iso app_server_2024_restored.iso如果两行输出的哈希完全一致说明文件没有问题。如果不想每次都手动对比两个值也可以生成校验文件后用-c参数自动检查md5sum app_server_2024.iso checksum.md5 md5sum -c checksum.md5输出OK就是通过输出FAILED就说明有问题。在实际项目中我更推荐用 sha256sum校验机制相同但更稳妥sha256sum app_server_2024.iso app_server_2024_restored.iso校验这一步真的不能省。我见过太多人传输大文件后不校验就直接解压结果解到一半报错才发现分片顺序错了或者某个分片损坏又要重新传一遍。多花十几秒做一次哈希比对能省掉几小时的重传时间。3.3 合并时不能忽略的三个坑第一个坑是磁盘空间。合并过程中会同时存在所有分片和目标文件目标文件大小等于原文件大小所以磁盘剩余必须大于原文件大小。用df -h提前确认别等写满磁盘报错才反应过来。第二个坑是输出文件的命名。合并命令cat app_iso_tmp_0* 某个文件输出文件千万不要叫app_iso_tmp_合并之类还带前缀名字因为重定向会先把输出文件截断如果这个文件恰好又匹配了前面的通配符就会把源分片直接清空。我自己的习惯是把合并结果输出到另一个目录或者起一个完全没有关联的名字比如restored.iso。第三个坑是中断。合并是大文件读写耗时可能比较长中途按 CtrlC 会留下一个残缺的目标文件。关键是你很难判断残缺到什么程度后续检查时容易被误导。建议合并前先确认源分片都在合并过程中尽量不要中断或者干脆在脚本里加上trap处理中断时自动删除半成品文件。4. 分卷归档、dd 级切割与流式处理4.1 tar 配合 split 做目录分卷打包如果我要切割的不是单个文件而是一个大目录直接用 split 切目录是不行的因为 split 只能处理文件。标准做法是先用 tar 把目录打包成流再交给 split 分卷。打包并分卷的命令tar -czv -f - ./project_dir | split -d -b 2G - part_backup.tar.gz.这里-f -表示 tar 输出到标准输出不生成文件split 的-表示从标准输入读取。注意我用-c做了 gzip 压缩所以分片名字带有.tar.gz.前缀加数字后缀。2GB 一片适合放到大多数文件系统。恢复的时候可以直接流式合并解压cat part_backup.tar.gz.* | tar -xzv -f -也可以先合并成完整 tar 文件再解压cat part_backup.tar.gz.* full_backup.tar.gz tar -xzvf full_backup.tar.gz第一种方式的好处是不需要额外的磁盘空间存放合并后的文件直接边合并边解压非常省空间。坏处是如果解压中途出错排查起来没那么直观。第二种方式适合事后还要保留完整备份包的场景。一个常见的失败情况是解压时报gzip: stdin: not in gzip format。这通常不是 gzip 本身坏了而是分片顺序不对。检查一下分片文件名是不是part_backup.tar.gz.000、part_backup.tar.gz.001……如果命名不规则用sort -V排序后再合并。4.2 dd 精确到字节的切割与拼装split 是按顺序切分整个文件而 dd 更适合“按偏移量精确读取某一区段”。比如我有一个磁盘镜像storage.img只想取出从 100MB 处开始的 50MB 数据dd ifstorage.img ofrescue_part.bin bs1M skip100 count50 statusprogress这里的bs1M是每次读写块大小skip100表示跳过 100 个块也就是跳过 100MBcount50表示读取 50 个块即 50MB。statusprogress会显示实时进度。注意 dd 的参数含义skip和count的单位是“块”块大小由bs决定。很多人把skip100理解成“跳过 100 字节”那就差远了。如果确实需要精确到字节可以把bs1但那样读写效率会非常低大文件切分时基本不这么用。把分片写回指定位置用dd ifrescue_part.bin ofstorage_restored.img bs1M seek100seek100表示写入时跳过目标文件前 100 个块从第 101 块开始覆盖。这种方式适合在已有文件上打补丁比如修复某个偏移处的数据块。但如果你把seek用在一个不存在的文件上dd 会创建一个稀疏文件前面 100MB 内容是空洞这在某些场景下可能不是你想要的需要注意。dd 是底层命令if 和 of 写反、bs 设置错误都可能瞬间把源文件清空或者写出垃圾数据。实际使用中我建议先在测试文件上演练一遍再操作真实数据尤其是of指向的数据很重要的场景。4.3 流式传输与远端解包大文件切割和传输经常是串在一起做的。跨服务器传数据时我常用这种管道组合tar -czf - ./data | split -b 500M -d -a 3 - data_tgz_ scp data_tgz_* 远端主机:/目标目录/到了远端一条命令完成合并解压cd 目标目录 cat data_tgz_* | tar -xzf - -C ./接收目录这整个流程中本地不会出现完整的打包文件每个分片只有 500MB传输时哪个分片失败就单独补传哪个非常灵活。如果中转平台只允许单文件不超过某个大小这个方案基本能应对任何限制。配合 pv 命令还能显示传输和解包进度cat data_tgz_* | pv | tar -xzf - -C ./接收目录5. 常见问题与排查技巧实录把我在实际使用中遇到过的问题整理成了一份速查表你可以直接对照排查。问题可能原因解决方案合并后 md5/sha256 不一致分片顺序错乱、某个分片损坏、切割单位混用用 sort -V 排序合并重新比对每个分片大小和哈希split 报“输出文件后缀已用完”分片数量超过-a支持的上限增大-a如-a 4或改用更大分片大小cat 合并出来的 tar 解压报格式错误分片顺序不对或某个分片不完整用ls -l对比各分片大小用sort -V排序后重试合并时磁盘空间不足磁盘剩余小于原文件大小清理磁盘或改用流式合并解压方式传输到一半某个分片丢失网络中断、存储介质异常只补传缺失分片不需要重传整个文件用-b 100M切完文件最后一片和预期大小不符文件总大小不是分片大小的整数倍这是正常的不需要处理最后一片小于设定值即可FAT32 移动硬盘复制仍提示文件过大切分后的分片还是超过 4GB修改分片大小确保单片小于 4GB合并时通配符匹配到了多余文件前缀命名不够独特或目录里混入其他分片改用特征更明显的前缀输出文件放到独立目录下面几个场景比较典型我单独展开讲讲。第一个是分片数量超过预期。如果split -b 100M -d -a 2切一个 50GB 的文件需要 500 个分片而-a 2最多只支持 100 个数字后缀00 到 99split 会在第 101 个分片时报错。这时候不要慌已经切好的分片还在只是命名已经到达上限。解决方法是重新用-a 3或-a 4切一遍或者改用更大的分片大小。第二个是合并出来的文件能解压但内容损坏。有人合并后能正常打开压缩包但解出来的文件缺失一部分这种情况通常不是顺序错而是某个分片在传输过程中被截断或者填充了空数据。排查方法是ls -l逐一确认每个分片大小是否与切割时一致同时对每个分片做一次 md5sum和切割完成后生成的校验清单比对。我在切割完成后会顺手生成一份分片 hash 清单md5sum app_iso_tmp_* part_checksums.md5传输合并后再执行md5sum -c part_checksums.md5哪一片有问题一目了然。第三个是超大文件 hash 计算太慢。对大文件做完整 sha256 可能要几分钟有时候不想等我会上传后只对比总大小和最后一个分片的哈希作为快速边界检查。如果总大小一致、最后一个分片 hash 一致文件基本不会有问题但严谨场景还是建议做完整哈希校验。第四个是远程传输分片时ssh 会话被终端断开导致中断。推荐使用 nohup 加后台运行或者直接写脚本让分片逐个 scp失败自动重试。这个不属于切割命令本身的问题但在大文件传输场景里非常影响体验列出来供参考。6. 我这些年用下来的个人心得切文件这件事技术含量不算高但我发现很多人吃亏都吃在“切之前没想好怎么合”。命名规范、分片顺序、校验清单这三样比切分命令本身更重要。我现在的固定流程是切分前先确认目标磁盘空间用split -b 大小 -d -a 3统一命名切完立即生成一份 md5 清单传输完合并后执行md5sum -c校验全部通过才删除源文件。这套流程用顺手之后我再也没有因为大文件传输出过事故。最后分享一个小技巧split 命令本身支持--filter参数可以在切分的同时对每个分片做进一步处理比如边切边压缩。比如你想把一个大日志文件按 100MB 切完并各自压缩split -b 100M --filtergzip $FILE.gz big_log.txt part_log_这样每个分片都会生成对应的part_log_000.gz省得合并后想用的时候还要重新解压。不过这个参数在 macOS 自带的 split 里不一定支持Linux 下实测没问题。如果你主要用 Linux 服务器可以放心用。
