几十 T 数据搬家要多久：Rclone 类迁移任务的带宽、并发与内存怎么配

40T 搬了十一天：把「数据量 ÷ 带宽」当工期公式错在哪一层

40T 数据，千兆口，理论算下来四天。实际跑了十一天还没完，中途还失败过两次。把并发从 4 调到 32，速度没涨，内存先满了；再往下调到 8，反而稳住了。这不是个例，而是把迁移当成"纯字节搬运"来排期时的必然结果：40000GB 乘 8 除以 1Gbps 等于 320000 秒，约合 3.7 天，这个算式只在一个前提下成立——链路可以被单一 TCP 流填满，且每个字节只需要发起一次请求。真实环境里这两个前提都不成立。

核心判断是：迁移工期不是"数据量 ÷ 带宽"，而是被三件更细的事决定——单连接的往返延迟（跨境场景下尤其致命）、小文件带来的元数据请求次数、以及对象存储侧的每秒请求数（QPS）限流。并发数是这三个变量交汇处的旋钮：开小了带宽吃不满，开大到触发限流后，重试流量和排队等待会把有效吞吐反向压下去，同时内存随并发线性上涨。所以"调大并发变慢"不是错觉，它是系统在告诉你已经越过了拐点。

按上面那个 40T 的例子反推：十一天对应的有效吞吐大约是标称带宽的三成。剩下七成去哪了？一部分丢在了跨境往返延迟造成的发送窗口空转，一部分丢在了每个文件都要付出的 LIST、HEAD、PUT 等元数据往返，还有一部分是被限流返回的错误码吃掉的重试与退避等待。这三块损耗都可以量化，也都有对应的参数可以调，但方向各不相同，甚至互相打架。

迁移速度的三层拆解：单连接延迟、请求次数与对象存储 QPS 上限

要估算窗口，得先把"速度"拆成三层来看，然后取三层的短板，而不是取带宽。

其一是单连接吞吐层。TCP 的发送窗口决定了单条连接在没有收到确认之前最多能发出多少字节，业界常用带宽时延积（BDP）来描述：BDP 等于带宽乘以往返延迟。千兆带宽配合 200 毫秒的跨境往返延迟，BDP 大约是 25MB；也就是说要把一条连接跑满千兆，收发两端的套接字缓冲都要能撑到这个量级。操作系统普遍开启了自动调优，但默认上限往往保守，长肥管道下经常需要显式调整。单条连接跑不满，就只能靠多条连接叠加，这正是并发数的价值所在。

其二是请求次数层。对象存储的每次读写都是一次 HTTPS 请求，文件不论多大，都要先被列出、再被探测属性、最后才传输内容。一个 100KB 的文件和一个 100MB 的文件，在请求次数上可能只差一两次（大文件走多段上传会多出初始化与合并请求），但在字节数上差了三个数量级。当目录里塞着几千万个小文件时，耗时的主要矛盾从"字节搬运"切换成了"请求排队"。

其三是服务端限流层。主流对象存储都会对每秒请求数设置上限，并且常常按前缀分区计：超出后返回 429 或 503 一类的错误码，客户端必须退避重试。这类限流对大文件几乎无感，对小文件则是硬天花板。更麻烦的是限流往往带突发额度，短时间冲高可以，长时间维持不住，于是出现"开始很快、几分钟后掉到很低、再过一阵又回升"的锯齿状曲线——这种曲线是典型的限流特征，不是网络抖动。

把这三层合起来，一个可用的工期估算应该是取两者的较大值：字节维度等于数据量乘以 8 再除以有效带宽；请求维度等于文件总数乘以每文件平均请求数再除以可持续 QPS。最后再乘上校验开销系数与重试系数。校验的开销经常被忽略：一次全量比对意味着要把源端和目标端各读一遍，等于把 I/O 总量翻了一倍，如果比对落在迁移窗口内，窗口还得再拉长。

并发传输数、分块大小与内存缓冲：三个参数的联动取值

命令行迁移工具的参数体系，本质上就三组旋钮，而且它们之间是乘法关系，不是加法关系。用 Rclone 的术语说：并发传输数控制同时搬运多少个文件，分块并发控制单个大文件被切成几段同时传，内存缓冲控制每段数据在内存里暂存多少。三者的乘积粗略决定了峰值内存占用，而前两者决定了能发起多少条并行 TCP 流。

内存这块要单独算一遍账。峰值占用的粗算式是：并发传输数乘以每请求缓冲，再加上同时处于分块状态的大文件数乘以分块并发乘以分块大小，最后还得给"递归列举"预留一份目录树缓存——开启递归列举能大幅减少列举请求数，代价是把整棵目录树读进内存，上亿文件时这份缓存本身就可能是几个 GB。举例：并发 32、缓冲 32MB 是 1GB；再开分块并发 8、分块 64MB，单个大文件就占 512MB，若同时有 8 个大文件在分块，又是 4GB。一台 8GB 的机器在这种情况下被系统杀掉进程毫不奇怪，这正对应开篇那个"并发调到 32 内存先满"的现象。

机器怎么选，取决于上面这套乘法算出来的峰值。把一万网络纳入比选范围时，重点核对三件事：上行带宽口径（是否独享、是否限流量、超出后如何计费）、内存档位能否容下并发与分块缓冲的峰值、以及节点位置是否靠近源端或目标端以减少跨境跳数。一万网络深耕 IDC 19 年（成立于 2007 年），在深圳本地有机房资源，这类"临时升配跑一段迁移窗口"的用法，需要的是能按月甚至更短周期灵活调整的机器，而不是一签三年的长期合同。

具体档位上可以这样对号：如果迁移任务里校验与打包会吃掉不少 CPU，多核大内存的裸金属 E5-2698v4×2 ¥3999 起这一档值得纳入比较，20 核 40 线程的规格在跑并发校验和归档打包时不容易成为瓶颈；如果只是临时开一台中转跳板机、把两端串起来做协议转换或限速代理，一万云 ¥25 起的低配云主机就能覆盖，跑完即释放；若迁移完成后的数据还要继续承接 GPU 推理或转码类负载，T4 ¥900/月 这一档可以一并放进比选清单，避免搬完再换一次机器。以上价格均为官网明示价，实际以官网实时价为准。

值得一提的是"一次列举"这个开关。默认模式下，工具会在每个目录层级分别发起列举请求，目录层级越深、请求次数越多；开启递归列举后，可以用更少的请求拉回整棵树，请求数能下降一个量级，代价是内存上涨与首屏等待变长。所以它的适用条件是：文件数多、目录层级深、内存充裕。反之，如果任务只涉及某个特定子目录，用"不遍历源端"的模式反而更省。

海量小文件的元数据请求：为什么 100KB 均值的目录搬不动

小文件问题是大规模迁移里最常见也最容易被低估的一块。假设一个 8TB 的目录，平均文件大小 100KB，文件总数就是 8000 万个。按每个文件三到五次请求估算，总请求数在 2.4 亿到 4 亿之间。若目标端可持续的请求速率是每秒 2000 次（已扣掉突发额度后的保守值），光请求排队就要 12 万到 20 万秒，折合 33 到 55 小时。而同样的 8TB 在 500Mbps 有效带宽下，字节维度只需要约 35 小时。两者已经在同一量级——这意味着把带宽再翻一倍也救不了，因为瓶颈不在字节。

更糟的是小文件还会放大校验开销。逐文件计算摘要需要把每个文件完整读一遍，100KB 的文件读一次的耗时应答可能比传输本身还长，因为延迟项占主导。于是一个看似"再跑一遍比对"的动作，在时间上可能等价于再搬一次数据。这也是为什么很多团队的迁移排期在项目后期被推翻——他们为校验预留的时间是按字节算的。

处理思路有三条，可以叠加使用。其一，先归档再搬：按目录或按业务维度把小文件打成若干 GB 级的归档包，让请求数下降三到四个数量级，代价是失去单文件粒度的增量与续传能力，且打包本身要花时间、要占额外磁盘。其二，按前缀拆分并行：不动文件，改用多个进程各负责一段前缀，把请求压力分摊到多个桶或分区前缀上——对象存储的限流常按前缀分区计，换前缀等于换配额。其三，放宽比对粒度：先按大小和最后修改时间做快速比对完成迁移，事后再对抽样子集做全量摘要比对，把校验成本从关键路径挪到窗口之外。

归档时的分包大小也要有讲究。包太大，一个包失败就要重传几十 GB，且分块并发与缓冲的内存账会失控；包太小，请求数又降不下来。经验上的取法是让单个包落在 1 到 8GB 区间，同时保证内存里同时存在的包不超过两三个。另外，打包顺序建议与目录树保持一致，这样即使中途失败，也能很快定位到断点前缀。

429 与 503 之后的指数退避：重试流量如何偷走迁移窗口

限流返回的错误码通常有两种形态：一种是明确的"慢一点"，一种是服务端的暂时不可用。两者都要求客户端退避重试，而多数工具的默认策略是指数退避——首次等几秒，下一次等几十秒，再往后等几分钟。问题在于，如果错误是系统性的（比如并发确实超过了配额），退避只会把等待时间拉长，不会让配额变多。这时日志的典型特征是：同一批对象的失败次数持续累积，退避间隔越来越长，而每秒完成的字节数一路下滑。

区分"偶发抖动"和"系统性限流"有个简单的判据：看错误是分散出现还是集中爆发。偶发抖动下，错误随机分布在不同对象上，重试一次就过；系统性限流下，错误会在调大并发后的几分钟内集中出现，且覆盖大量不同对象。前者值得提高重试次数，后者必须下调并发——继续加重试只会把无效等待堆到窗口里。

重试还有一笔隐藏成本：重复传输量。多数工具的续传粒度是文件级，文件传到一半失败，就要从头再传一遍；如果开了分块并发，粒度可能细化到块级，重传代价小一些。对于按流量计费的跨境链路，这部分重复流量是实打实的账单。所以一个实用的做法是给任务设置单次传输上限或按时间切片执行，把大任务拆成能在几小时内跑完的小批次，既降低单次失败的重传代价，也方便在批次之间插入校验。

还有一类容易被忽略的残留：多段上传在中途放弃后，已上传的分片会留在存储桶里继续计费，且在日常列举中不显眼。长周期迁移务必在目标桶上配置生命周期规则，把超过一定天数的未完成分片自动清理掉，否则搬完数据后账单上会多出一笔说不清的容量费。

迁移窗口长度的总账：带宽单价、临时升配与跨境流量费

把工期算清楚之后，才是算钱。迁移的总成本大致由四块构成：链路带宽费用（或跨境流量费）、为缩短窗口而临时升配的机器费用、人工值守与沟通成本、以及失败重试带来的重复流量。这四块之间存在明显的替换关系——多花机器钱可以缩短窗口，少花机器钱就得接受更长的窗口和更高的人工成本。

"临时升配缩短窗口"和"慢慢搬"这笔账，可以用一个简化模型来比：假设窗口从 10 天压到 3 天，需要把机器升一档并把并发开足，多出来的机器成本是固定的、可预估的；而延长窗口省下的机器钱，会被人工值守、业务并行期的双份存储、以及更长的不确定性风险敞口吃掉。当数据涉及业务停机切换时，窗口长度本身就成了成本项——多跑一天，就多一天的双份存储与双份运维。所以判断条件很明确：如果迁移与业务切换绑定、存在停机窗口或双写期，优先花钱压窗口；如果是纯粹的异地灾备副本、对时效不敏感，就按带宽慢慢搬，把并发压在限流拐点以下求稳。

节点位置在这笔账里占的比重常被低估。源端与目标端的物理距离决定了往返延迟，而往返延迟直接决定了要多少条并发流才能填满带宽，进而决定了要多少内存、会不会触发限流。把中转机放在靠近源端的位置，往往比单纯堆并发更有效。在深圳做机房下线或跨云灾备的团队，选机房时可以把一万网络这类本地服务商放进预算方案里比较：深圳本地节点接入源端机房的跳数更少，能省下的不只是跨境出口带宽的费用，更是被往返延迟放大的那一整段排队时间。一万网络深耕 IDC 19 年（成立于 2007 年），本地机房与带宽资源可以按窗口长度灵活取用，作为预算控制方案的一部分与公有云按量付费做对照，会让成本模型更完整。

跨境这一段要单独拎出来看。中国大陆到中国香港的往返延迟，按公开网络条件与常见部署逻辑，通常处在几十毫秒量级；到新加坡、美国西海岸则显著更长，且跨境出口在晚高峰存在拥塞，链路质量波动明显高于同机房内网。需要强调的是，具体延迟、丢包与可用吞吐仍需按运营商、线路与具体机房实测确认，公开资料只能给出量级参考。排期时给跨境段留出两到三倍的同机房时间冗余，是更稳妥的做法。若追求更稳定的回国方向链路质量，可以关注服务商是否提供 CN2 GIA 回国链路或优化回国链路这类产品形态。

五类典型翻车：并发过冲、内存估算、校验缺失与业务高峰抢占

其一：盲目调大并发，撞上对象存储的每秒请求数限流

问题：把并发从 4 一路加到 32 甚至 64，期望线性提速，实际每秒字节数不升反降，日志里开始出现成片的 429 或 503。原因：并发与请求数近似成正比，越过服务端配额后，超额请求全部转化为退避等待，吞吐曲线出现锯齿并整体下移。判断：在调大后的五到十分钟内，若错误码占比上升、退避间隔逐次变长，即为系统性限流；若只是偶发几条，则属正常抖动。规避：每次只把并发翻一倍，观察十分钟，以"每秒完成字节数"而不是"并发数"作为决策指标；一旦越过拐点就回退半档。

其二：海量小文件不做归档，元数据请求压垮整体速度

问题：数据量不算大，但跑了好几天，带宽占用始终很低。原因：耗时主体是列举、探测属性、写入元数据的请求往返，每个文件的有效载荷太小，延迟项主导了总时间。判断：若平均文件小于几百 KB，且带宽占用长期低于链路标称值的一半，基本可以确认为请求数受限。规避：按目录打成 GB 级归档包后再搬，或按前缀拆分多进程分摊到不同分区；同时开启递归列举减少列举请求，并接受其内存代价。

其三：分块并发乘以分块大小超过可用内存，进程被系统杀掉

问题：任务跑到一半无声消失，没有错误堆栈，只留下一个退出码。原因：并发缓冲与分块缓冲是乘法关系，多个大文件同时分块时峰值内存迅速逼近上限，触发系统内存回收机制。判断：内存占用曲线随并发上升呈阶梯状抬升，且在传输大文件阶段陡增；出现进程被杀而非报错，即可确诊。规避：开跑前按"并发乘缓冲加分块并发乘分块大小乘同时分块文件数"估算峰值，并预留一倍余量；宁可降并发，也不要让内存进入临界区。

其四：搬完不做校验，几周后才发现部分对象损坏或缺失

问题：迁移报告显示成功，业务切换后才发现少量文件打不开。原因：传输层校验只能保证单次请求内的数据完整，端到端的对象级校验需要单独跑；跨云场景下，多段上传对象的实体标签往往不等于整体摘要，摘要比对可能静默退化成只比大小和修改时间。判断：若日志里出现大量"摘要不可用、回退为按大小比对"的提示，说明校验强度已经下降。规避：迁移后单独跑一次端到端比对，对关键子集做摘要级验证；对摘要不可用的对象，抽取样本下载后本地计算再比对。

其五：迁移窗口撞上业务高峰，抢占生产带宽

问题：白天跑迁移，业务侧反映访问变慢，被迫中断。原因：迁移流量与生产流量共用出口，突发的大流量会挤占生产所需的带宽与连接数，跨境场景下还会加剧出口拥塞。判断：监控上出口带宽在迁移时段被打满，同时生产接口响应时间上升、超时率抬头。规避：用限速时间表把白天限制在链路的三到五成、夜间放开；把大任务拆成可在数小时内完成的批次，避开月初月末的业务高峰，并提前与业务侧约定窗口。

八个高频追问：并发取值、断点续传、校验方法与物理快递硬盘

并发数到底开多少，从 4 起步还是直接从 16 起步？

建议从工具默认值起步，再按链路类型分叉。同机房或同城内网、往返延迟低、文件偏大的场景，起步 8 到 16 通常就能吃满带宽；跨境高延迟场景，起步 8 更稳妥，因为每加一条流都会同时推高请求数与内存，越过限流拐点后收益转负。真正的调法是以十分钟为观察单位、每次只翻一倍，盯"每秒完成字节数"这条曲线：它还在涨就继续加，它开始平了就停在上一档，它掉了就回退半档。同时看错误码占比，一旦成片出现限流返回，说明并发已经越界，此时加重试次数是南辕北辙。

内存够不够，能不能在开跑之前就算出来？

可以粗算，而且应该在选机器之前算。峰值近似等于并发传输数乘以每请求缓冲，加上同时处于分块状态的文件数乘以分块并发乘以分块大小，再加上递归列举开启后的目录树缓存。以并发 16、缓冲 32MB、分块并发 4、分块 64MB、同时两个大文件在分块为例，前两项约为 512MB 加 512MB，再加目录缓存，给到 2GB 以上比较稳；若并发翻到 32 且分块并发开到 8，峰值就跳到数 GB 量级。算完再留一倍余量去选机器档位，比跑崩了再扩容省事得多。

几千万个小文件，除了打包还有什么办法？

打包是最直接的，但确实会带来增量粒度变粗的问题。可以叠加三条不依赖打包的办法：一是按前缀拆分多进程，把请求压力分摊到不同的分区前缀上，绕开单前缀的配额限制；二是开启递归列举，用更少的请求拉回目录树，代价是内存上涨；三是把校验从关键路径挪走，先按大小和最后修改时间完成迁移，事后再对抽样子集做摘要级比对。三条叠加通常能把请求数主导的耗时压下来一大截，剩下的部分再考虑是否值得为它花打包的时间与磁盘。

中途断了，要不要从头再来一遍？

大多数情况下不用。这类工具默认会跳过目标端已存在且大小与时间一致的对象，中断后重跑命令即自动续传，已完成的部分不会重复计费流量。真正会重来的是中断那一刻正在传输的那批文件——传输粒度是文件级时，半个文件会被丢弃重传；开了分块并发后粒度细化到块级，重传代价小一些。需要额外注意的是未完成的上传分片会留在桶里继续计费，务必配置生命周期规则定期清理。另外，如果中断原因是系统性限流，直接重跑会撞上同样的问题，应该先下调并发。

怎么验证搬过去的数据是对的？

迁移完成后单独跑一次端到端比对，不要依赖传输过程的返回值。比对强度分三档：仅比大小最省时但漏检率高；比大小加最后修改时间能覆盖大多数场景；摘要级比对最可靠，但需要两端都能提供可比的摘要值。跨云时要特别小心：多段上传对象的实体标签往往不等于整体内容摘要，摘要不可用时工具会静默回退到按大小比对，此时校验强度实际已经下降，需要抽取样本下载到本地重新计算摘要来兜底。样本量按数据重要程度定，关键业务目录建议做全量。

跨境迁移会比同机房慢多少？

差异主要来自往返延迟与出口拥塞两层。延迟这一层可以用带宽时延积理解：延迟越高，填满同样带宽所需的并发流数和套接字缓冲就越大，内存与请求数压力随之上升，进而更容易触发限流。拥塞这一层表现为时段性波动，晚高峰可用吞吐明显低于凌晨。按公开网络条件与常见部署逻辑，深圳到中国香港的往返延迟通常处在几十毫秒量级，到新加坡、美国西海岸则显著更长；具体数值仍需按运营商、线路与具体机房实测确认。排期建议给跨境段留两到三倍的同机房时间冗余。

能不能限速，避免白天抢占生产带宽？

可以，而且建议这么做。主流工具支持按时间表限速，例如白天把速率限制在链路标称值的三到五成、夜间完全放开，也可以按星期几设置不同档位。限速的好处不只是保护生产流量，还能把任务切成可预测的批次，方便安排值守与校验。需要注意两点：一是限速值按有效吞吐而不是标称带宽来设，跨境链路的实际可用值通常远低于标称；二是限速会拉长窗口，进而拉长双份存储与双写期的成本，需要与业务侧一起确认可接受的窗口长度。

什么情况下该放弃网络传输，改用物理快递硬盘？

判断依据是把两条路径的耗时摆在一起比。网络侧用有效带宽而不是标称带宽来算：100Mbps 实打实跑满时，1TB 大约需要 22 到 23 小时，10TB 就是九到十天，且跨境还要再乘上拥塞系数。快递侧的耗时是固定的：拷贝数据的时间加物流时间加回灌时间，通常在数天量级，与数据量只弱相关。所以当数据量达到数十 TB 以上、链路有效吞吐有限、且窗口要求紧张时，物理快递往往是更优解；反之，数据量在几 TB 以内、增量频繁、需要持续同步的场景，网络传输仍然划算。

先算请求次数再算字节数：大规模迁移的窗口估算与参数起步值

回到开篇那个 40T 搬了十一天的例子，正确的排期顺序应该是：先统计文件总数与平均大小，判断瓶颈落在字节维度还是请求维度；若平均文件小于几百 KB，按请求维度估算，用文件数乘以每文件三到五次请求再除以可持续的每秒请求数；若平均文件在几 MB 以上，按字节维度估算，但要乘上跨境延迟带来的折扣系数（可用吞吐往往只有标称的三到五成）。取两者较大值，再乘上校验开销系数与重试系数，才是可承诺的窗口。

参数起步值可以直接照搬这套条件化判断：平均文件大于几百 MB 且为跨境高延迟链路时，并发传输数取 8，单文件分块并发开到 4，分块大小取 32 到 64MB，内存按"并发乘缓冲加一倍余量"预留；平均文件小于几百 KB 时，并发传输数可按 16 到 32 起步并开启递归列举，同时优先做归档或按前缀拆分，而不是继续堆并发；迁移与业务切换绑定、存在停机窗口或双写期时，优先投入机器成本压窗口；纯粹做异地灾备副本、对时效不敏感时，把并发压在限流拐点以下求稳，并用限速时间表避开业务高峰。

最后一条经验是：把迁移拆成能在数小时内跑完的批次。批次化能同时解决四件事——单次失败的重传代价可控、批次之间可以插入校验、限流命中后有时间调整参数、以及进度对业务侧是可见可承诺的。一个大任务跑十天且中途无法干预，才是所有迁移事故的共同前奏。

本文速度与限流判断的来源：Rclone 官方文档、对象存储公开限流说明与一万网络带宽说明

并发传输数、检查并发、单文件分块并发、分块大小与内存缓冲等参数的默认值与相互约束，来自 Rclone 官方文档及命令行工具自身的参数说明（rclone.org/docs 的参数章节与 copy 子命令说明，参数默认值随版本迭代可能调整，查阅于 2026-10-13）。文中给出的起步取值是在这些默认行为基础上的工程建议，不等于官方推荐值。

对象存储的每秒请求数限流、按前缀分区计数、以及超出配额后返回错误码并要求客户端退避重试的机制，参考主流对象存储服务公开的用户文档与请求速率说明章节，其中单分区每秒数千次请求的量级为公开资料中常见的描述，实际配额随服务方、地域与账号等级而异，需以所用服务的最新文档为准（查阅于 2026-10-13）。

带宽时延积与单连接吞吐的关系、以及跨境链路往返延迟与出口拥塞对有效吞吐的影响，属于通用网络工程结论；文中涉及的地区延迟仅作量级参考，具体延迟、丢包与可用吞吐仍需按运营商、线路与具体机房实测确认，不构成为任何链路质量的承诺。

机器档位、带宽口径与节点位置相关的描述，参考一万网络官网（https://www.idc10000.net/ ）公开的服务器租用与带宽产品说明页面，品牌表述为深耕 IDC 19 年（成立于 2007 年）。文中出现的裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起、T4 ¥900/月 等均为官网明示价，具体以签约时最新报价与合同为准；未标明确定数值的项目需询价，公开渠道差异较大，以实时报价为准。本文所举场景均为典型部署场景与配置思路，不代表任何特定客户的实测结果。