服务器拷贝4T文件想快，核心思路是先测清瓶颈再选方案，机械盘堆硬件、小文件靠打包、跨机房走并行，普遍情况下用rsync加调优参数能把速度拉满。
先弄明白这4T数据卡在哪一环
4T文件拷贝慢,业内专家指出瓶颈通常不在硬盘容量，而在三个地方：源盘读取速度、网络链路带宽、目标盘写入速度，很多人在服务器上拷数据时第一步就错了直接丢一个scp或cp命令然后干等，实际上这4T文件可能只是被一个慢速磁盘拖住了。
动手之前先花两分钟做个判断,你的4T文件是大文件为主，还是大量小文件？这决定了完全不同的策略，如果是一堆几KB的日志或图片，文件数量可能超过百万级，这时候带宽根本不是问题，寻址时间才是大头，如果是几个几TB的镜像文件，那纯看带宽上限，方法简单得多。
另一个判断维度是源服务器和目标服务器是否在同一机房，同机房内网千兆和跨地域公网传输，完全是两个量级的问题，同机房内网传输4T数据，千兆带宽理论极限也就每秒110MB左右，跑满大概需要10小时；如果是万兆内网，这个时间能压缩到1小时出头。
从慢到快，4T文件拷贝的三种主流方案对比
拿不准用哪种方案时,先看下面这张对比表，基本能覆盖大多数服务器间拷贝4T文件怎么快的需求场景。
| 方案 | 适用场景 | 核心优势 | 明显短板 |
|---|---|---|---|
| scp | 临时传小文件 | 命令简单、无需配置 | 不支持断点续传，中断后前功尽弃 |
| rsync | 常规备份、增量同步 | 断点续传、可限速、增量传输 | 海量小文件时比tar管道慢 |
| tar + 管道 | 几十万以上小文件 | 打包后传输，减少寻址损耗 | 两端需同时操作，命令略复杂 |
| 并行多通道工具 | 跨机房、带宽充足 | 多连接并发，吃满带宽 | 需要额外安装软件，配置复杂 |
不少人在服务器上拷贝4t文件怎么快的方案里选scp,图省事，但4T这种量级，网络抖动一次就全盘重来，相当不划算，rsync在大多数情况下是更稳妥的选择，断点续传让中途意外断电也不至于前功尽弃。
实操：用rsync把4T文件拷贝速度拉到极限
先测瓶颈，别让配置白做
执行拷贝之前,先用三个命令判断瓶颈位置：
# 测源服务器磁盘读取速度 dd if=/dev/sda of=/dev/null bs=1M count=1024 # 测网络带宽（两端都要装iperf3） iperf3 -s # 服务端 iperf3 -c 服务器IP # 客户端 # 看目标盘是机械盘还是固态盘 lsblk -d -o name,rota
rota等于1说明是机械盘，等于0是固态盘，如果源盘是7200转机械硬盘，顺序读取也就150-200MB/s，这时候换什么网络协议都白搭，磁盘本身已经是天花板，如果拷的是云服务器，还涉及云盘类型，普通云硬盘的IOPS比本地盘低一截，这也是内网服务器传输文件速度慢怎么办时容易忽略的盲区。
rsync配合tar管道处理海量小文件
4T数据如果由几十万个文件组成,直接用rsync同步会让每个文件都产生一次磁盘寻址和网络握手，速度会拖到惨不忍睹，行业共识认为，遇到这种情况应该先用tar打包再传，让顺序读代替随机读。
# 一条命令搞定打包和传输，不需要中间文件 tar cf - /data/4tfiles | ssh 目标IP "tar xf - -C /data/" # 如果你想看到进度信息 tar czf - /data/4tfiles | pv | ssh 目标IP "tar xzf - -C /data/"
这里的pv命令能实时显示传输速度和进度百分比，看4T大文件传输不再两眼一抹黑，注意-z压缩选项，除非数据本身是文本或日志，否则别加，4T的文件如果有相当一部分已经是压缩格式退出，比如ZIP、MP4、JPEG，压缩只是白白消耗CPU。
rsync的关键调优参数
如果文件大小比较均匀、没有太多零碎文件，下面这组rsync参数是经过大量实践验证的高效组合：
rsync -av --partial --progress --inplace --bwlimit=0 /data/4tfiles/ 目标IP:/data/4tfiles/
--partial保留已传部分--inplace原地更新目标文件，避免拷贝产生临时文件--bwlimit=0表示不限速- 如果你是万兆内网,换成
-e "ssh -c aes128-gcm@openssh.com"用更轻量的加密算法，减少CPU加密开销
用并行通道突破单连接限制
rsync走ssh时本质是单连接,TCP窗口和协议栈限制让它在高带宽、高延迟场景下吃不满带宽，跨地域机房之间，单条rsync可能只有几十MB/s，远低于公网实际带宽，这时可以同时开4到8个rsync进程，每个进程同步不同的子目录：
rsync -av /data/4tfiles/document/ 目标IP:/data/4tfiles/document/ & rsync -av /data/4tfiles/photo/ 目标IP:/data/4tfiles/photo/ & rsync -av /data/4tfiles/video/ 目标IP:/data/4tfiles/video/ & wait
注意不要对这些rsync进程的源文件目录重叠，文件会冲突，按业务模块或者按文件名首字母拆目轮询同步，是简单有效的方式。
大型文件：直接用Netcat跑满万兆
如果你在服务器上拷贝4t文件怎么快的场景里,刚好是两个内网互通的机器之间，而且文件本身是几个大块头，那么Netcat方案效率极高，它完全摈弃了加密、流控等开销，让数据裸奔在网络上，速度能打满网卡。
# 目标服务器先开启监听 nc -l -p 9000 | tar xf - -C /data/4tfiles/ # 源服务器发送数据 tar cf - /data/4tfiles/ | nc 目标IP 9000
这方案的风险在于没有传输校验，传完最好用md5sum校验一遍，4T文件的校验本身也需要不短时间，要看你对数据完整性的重视程度，内网环境、技术要求不敏感的场景下，这篇方案只要先比拼带宽比什么都强。
盘和卡的选择：服务器拷4T是硬件的活儿
如果你的服务器是自建机房,某些瓶颈是软件层面无法绕开的，目标服务器如果用的是SATA接口的机械盘，单盘顺序写不超过200MB/s，4T数据拷贝时间不可能低于5小时，这时候最直接的提速方式就是换盘或者做RAID。
把目标盘做成RAID0,写入带宽成倍增长，机械盘阵列能稳定跑到400-500MB/s，更彻底的方式是配一块NVMe SSD做接收缓存，等数据落完再转存到机械盘存储池，实际的Linux服务器拷贝大文件用什么命令的优化里，万兆网卡本身需要插PCIe 3.0 x8以上的插槽，否则接口带宽根本跑不满。
4T拷贝中途断了怎么办
断点续传方案在rsync里天然支持,很简单：
rsync -av --partial /data/4tfiles/ 目标IP:/data/4tfiles/
rsync执行时会先对比两端的文件大小、修改时间，对已传完的文件跳过，对没传完的接着传，这也是为什么开头说不要选scp传4T级别数据，scp没有续传能力，断了就是从头再来，传大数据期间尽量放在tmux或screen会话里跑，避免SSH断连导致进程被杀。
另外一个容易踩的坑是磁盘空间检查，4T文件传到目标端前，确认目标分区有至少4.3T以上空闲，因为rsync在部分传输场景下会额外消耗临时文件空间。
Q&A：服务器拷贝4t文件怎么快的高频追问
问：rsync传大文件时为什么忽快忽慢，怎么稳定速度？
答：大多数情况下，波动源于源目两端磁盘的读写突发和网络拥塞，rsync加--bwlimit参数可以限制峰值带宽，比如--bwlimit=50000限到50MB/s，降低抖动对业务的影响，另外检查两端网卡是否协商到正确的速率，线缆损坏或模块不兼容会导致自动降级到百兆。
问：4T数据里既有大文件又有海量小文件，怎么选方案？
答：建议混合策略大文件直接rsync，小文件所在的目录先用tar打到同一个临时归档里传输，避免那么多IO请求，归档文件传完到目标机再解包，意味着多占用一倍磁盘临时空间，但换来的是进度稳定，不卡顿，实际在处理混合负载时，先跑小文件打包传输，再同时跑大文件rsync，两个任务并行也能充分利用带宽。
问：源服务器在本地机房，目标服务器是某云厂商的云主机，内网服务器传输文件速度慢怎么办？
答：云主机和本地机房之间没有内网，只能走公网，瓶颈在上传带宽，首先确认云厂商的入方向带宽可以调大，其次重点建议用多通道并行方案，云主机一般有多核CPU，用openssl速度测试确认一下AES-NI硬件加速已经生效，如果百兆宽带的费用和延时都有限，就要接受一个现实跨公网传输4T文件按小时计算起步，选择rsync后台长期跑，或者用云厂商提供的离线迁移服务（寄硬盘）反而更快。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793437.html
