Nicholas Qin1. 为什么需要分割大型归档文件
在日常运维和数据处理工作中，我们经常会遇到需要处理大型归档文件的情况。一个完整的数据库备份、日志归档或者多媒体资源包，经过tar打包后很容易达到几十GB甚至上百GB的规模。这类大文件在传输和存储时会面临几个实际问题：
- 云存储服务对单个文件大小有限制（如AWS S3分块上传阈值为5GB）
- FTP传输大文件时网络中断需要整个重传
- 某些老旧文件系统（如FAT32）不支持超过4GB的单个文件
- 需要增量备份时无法只更新部分内容
我最近就遇到一个典型案例：客户现场的PostgreSQL数据库备份达到87GB，而他们的NAS存储剩余空间只有90GB。直接备份会导致存储空间告警，最终采用分割成20个4.5GB文件的方式解决了这个问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 归档文件分割方案对比
2.1 常见分割工具分析
在Linux环境下，主要有三种方式可以实现tar文件分割：
-
split命令：最基础的文件分割工具
bash复制split -b 2G largefile.tar largefile_part_优点：系统自带，无需安装
缺点：无法感知文件内容结构，可能破坏内部数据连续性 -
tar多卷功能：
bash复制
tar -cvz --tape-length=2048 -f largefile_part_.tar.gz file1 file2优点：保持压缩流完整性
缺点：恢复时必须按顺序处理所有分卷 -
自定义脚本+管道：
bash复制tar -czf - directory | split -b 2G - backup_part_优点：边压缩边分割，节省临时空间
缺点：出错后需要完全重试
2.2 方案选型建议
对于不同场景，我的经验建议是：
- 已存在的tar文件 → 使用split命令
- 需要从原始文件创建 → 采用管道方案
- 需要兼容Windows环境 → 确保分割大小是512字节的整数倍
3. 完整的分割与复原脚本实现
3.1 分割脚本详解
bash复制#!/bin/bash
# 参数检查
if [ $# -ne 3 ]; then
echo "用法: $0 [输入文件] [分割大小(如500M)] [输出前缀]"
exit 1
fi
input_file=$1
split_size=$2
output_prefix=$3
# 验证输入文件
if [ ! -f "$input_file" ]; then
echo "错误: 输入文件不存在"
exit 1
fi
# 执行分割
echo "开始分割 $input_file ..."
split -b $split_size --numeric-suffixes=1 --suffix-length=3 \
--additional-suffix=.part "$input_file" "$output_prefix"
# 生成MD5校验文件
echo "生成校验文件..."
md5sum ${output_prefix}* > ${output_prefix}md5sums
echo "分割完成！共生成 $(ls ${output_prefix}*.part | wc -l) 个分卷"
关键参数说明：
--numeric-suffixes=1：从001开始编号--suffix-length=3：保持3位数字编号--additional-suffix=.part：统一添加.part后缀
3.2 复原脚本实现
bash复制#!/bin/bash
if [ $# -ne 2 ]; then
echo "用法: $0 [分卷前缀] [输出文件]"
exit 1
fi
prefix=$1
output=$2
# 校验文件完整性
echo "正在校验分卷..."
if ! md5sum -c ${prefix}md5sums; then
echo "错误: 分卷校验失败"
exit 1
fi
# 合并文件
echo "开始合并分卷..."
cat ${prefix}*.part > "$output"
# 验证最终文件
if [ ! -f "$output" ]; then
echo "错误: 合并失败"
exit 1
fi
echo "成功合并为 $output"
3.3 使用示例
分割操作：
bash复制./split_tar.sh bigdata_backup.tar 2G backup_202306
将生成：
code复制backup_202306001.part
backup_202306002.part
...
backup_202306md5sums
复原操作：
bash复制./merge_tar.sh backup_202306 restored_backup.tar
4. 进阶技巧与注意事项
4.1 处理压缩归档的特殊情况
对于.tar.gz文件，有两种处理方式：
-
先分割后压缩（适合已有tar文件）：
bash复制split -b 1G file.tar.gz file_part_ -
边压缩边分割（推荐用于新创建归档）：
bash复制tar -czf - directory | split -b 1G - backup_part_
重要提示：不要尝试直接分割.gz文件，这会破坏压缩流导致无法解压
4.2 分卷大小选择建议
- 网络传输：建议10-100MB分卷
- 云存储：匹配服务商的分块上传阈值（如S3的5GB）
- 物理介质：考虑目标设备的簇大小（如4K对齐）
4.3 常见问题排查
问题1：合并后文件损坏
- 检查是否所有分卷都存在
- 验证md5sum是否匹配
- 确保合并顺序正确（按数字后缀排序）
问题2：解压时报"gzip: stdin: invalid compressed data"
- 可能是分卷边界破坏了压缩流
- 解决方案：改用
zcat流式处理bash复制cat parts* | zcat | tar -xvf -
5. 生产环境增强方案
5.1 断点续传实现
在分割脚本中加入进度记录：
bash复制# 在分割循环中添加
echo "$current_part" > ${output_prefix}.progress
恢复时检查进度文件：
bash复制if [ -f "${prefix}.progress" ]; then
last_part=$(cat "${prefix}.progress")
# 跳过已处理部分
fi
5.2 分布式存储适配
对接S3等对象存储的示例：
bash复制# 上传分卷
aws s3 cp ${output_prefix}* s3://my-bucket/backups/
# 下载并合并
aws s3 ls s3://my-bucket/backups/ | grep ${prefix} | awk '{print $4}' | \
xargs -I{} aws s3 cp s3://my-bucket/backups/{} .
5.3 性能优化技巧
- 使用
pigz替代gzip进行多线程压缩 - 设置合适的
ionice级别避免影响生产系统 - 对大目录采用
--listed-incremental做增量备份
我在处理一个5TB的日志归档时，通过以下组合将总耗时从18小时降到4.5小时：
bash复制ionice -c 3 tar -c --use-compress-program=pigz \
-f - /var/log | split -b 10G - logs_part_