多线程复制提升10倍：批量文件备份提速实战指南

刚处理完一次线上发布前的全量备份，源目录13.2GB，大小文件加起来有4万多个。以前用单线程复制，跑一次得25分钟左右，中间还不敢碰服务器。这次换成了多线程复制方案，同样的数据量，2分40秒跑完，顺带把校验、重试、日志都做了。没错，就是10倍左右的提升，而且代码量并不复杂。

这个问题的典型场景是这样的：后端服务器做版本发布前需要归档静态资源，或者把生产环境某几个目录整体备份到另一台机器/磁盘。数据量不大不小，几GB到几十GB，但文件数量特别多。这时候用单线程逐文件复制，瓶颈不在带宽，而在等待。每个文件从打开、读取、传输、写入到关闭，中间有大量IO等待时间，串行执行等于这些等待被累加到了一起。多线程的思路就是让这些等待重叠起来，让磁盘和网络始终处于忙碌状态。

本文适合两类人看：一类是后端开发，手头有备份脚本想提速；另一类是运维或测试，需要批量同步文件又不想引入太重型的工具。如果你对Java、Python、Go任一语言有基础，看完就能直接改出适合自己项目的版本。我会把方案选型、核心代码、参数调优和踩坑记录都写清楚，尽量做到拿来就能用。

1. 批量备份到底慢在哪：先定位瓶颈再动手

很多人一听到“多线程复制能提速”就直接开干，但实际效果往往差强人意，有时候甚至更慢。这里的问题不是多线程没用，而是没搞清楚慢的本质。备份慢，通常不是某一个环节慢，而是几个环节的慢被串行叠加了。

1.1 慢的不是复制动作，而是等待时间

单线程复制一个文件，实际经历的过程是：打开源文件、读取一块数据、写入目标文件、再读下一块，循环往复。这里真正让CPU干活的时间很少，大部分时间都花在了磁盘寻址、IO调度、网络往返这类等待上。举例来说，从机械硬盘读一个4KB的小文件，寻道时间可能就要几毫秒到十几毫秒，而真正传数据的耗时几乎可以忽略。

如果目录里有4万个文件，每个文件平均等待5毫秒，串行下来就是200秒。这个估算其实偏乐观，因为操作系统还有额外的系统调用开销、目录项更新开销。所以你会看到明明文件总大小不大，但备份就是跑得很慢。这和小包网络攻击拖垮服务器的道理类似——瓶颈不在流量大小，而在请求次数。

还有一类隐藏开销是目标端的写入。如果备份目标是机械硬盘，频繁的小文件写入会导致磁盘磁头不断移动，单线程下更是如此，因为每个文件写完后磁头要重新定位到新位置。这种情况下不仅慢，磁盘还一直在响，听起来就很不健康。

1.2 三种瓶颈对应的不同加速方式

批量备份的场景中，瓶颈大致可以分为三类：

• 元数据瓶颈：文件数量多，每个文件的打开、关闭、属性读取占用大量系统调用，CPU和内核开销明显。
• 磁盘IO瓶颈：数据量本身大，磁盘带宽被占满，这时候多线程意义有限，因为物理介质就这个速度上限。
• 网络延迟瓶颈：跨机器传输文件，每次IO往返都有网络延迟，单线程下延迟被逐文件放大。

如果是纯磁盘带宽打满的场景，比如在本地两块SSD之间复制一个几十GB的大文件，多线程几乎不会有提升。因为单线程已经可以把带宽跑满，再多线程反而会增加调度开销。但如果是大量小文件，或者跨机器的网络传输，多线程的收益非常明显，这也是标题里说提升10倍的现实基础。

所以动手之前先做个简单评估：你的目录是不是文件数量特别多？是不是从一台机器传到另一台机器？如果两个问题里有一个“是”，多线程方案就值得做。

1.3 多线程为什么能提速：让等待重叠起来

用生活中的场景来类比：去政务大厅办事，如果只有一个窗口，每个人办完才叫下一个号，那队伍后面的人只能干等。多线程相当于开了多个窗口，每个人在不同的窗口同时办，整体吞吐量自然就上来了。

在技术上，多线程复制文件的核心价值是并发掩盖延迟。当一个线程在等待磁盘返回数据时，另一个线程可以发起下一次读取；当一个文件在网络上传输时，另一个文件已经在本地写入。线程越多，同一时刻处于“等待中”的操作就越多，单位时间内能发起的IO请求也越多。

但并发不是越多越好。窗口开得太多，政务大厅的通道就堵了。线程数超过磁盘或网络的并发承载能力后，请求会在内核排队，反而增加调度负担。后面我会专门讲怎么定线程数，这里先记住一个结论：多线程的本质是用并发来塞满你的IO通道，而不是无限加大并发。

2. 方案选型：先看现成工具，再考虑写代码

在确定要自己写多线程复制之前，我建议你先看看系统自带工具。很多场景下，现成工具的一个参数就能解决问题，根本不值得写脚本维护。但如果你和我一样需要对接自定义流程，那代码方案还是更灵活。

2.1 自带工具中的“多线程代表”：Robocopy和Rsync

Windows环境下的Robocopy从Vista时代就支持多线程复制，参数是/MT。实测下来，/MT:16配合大文件和小文件混合的目录，速度提升明显。它默认会重试失败的文件，还支持复制ACL权限、时间戳等属性，非常适合做Windows服务器的目录迁移和归档。

Linux/macOS环境下的Rsync是传统方案，但原生rsync是单线程的。要并行，常见做法是把文件列表切分成多份，分别跑rsync进程。比如用xargs -P参数控制并发数，或者用parallel工具。另外，新一点的rsync版本支持--info=progress2显示总进度，但对端到端传输速度的提升没有直接帮助。

如果只是偶发性的手动备份，我建议直接用这些工具。Robocopy的/MT:32在文件数量大的场景下立竿见影，rsync配合xargs -P也能达到类似效果。它们的优势是经过大量生产环境验证，边缘情况处理得比你自己写的脚本靠谱。

2.2 现成工具不够用的时候：自研方案的四个理由

我自己写多线程复制脚本，是因为遇到了四个现成工具解决不了的问题。

第一，需要合并多个来源目录到同一个目标目录，并且带自定义的命名规则。Robocopy可以多线程复制，但跨多个源目录做聚合，它的表达能力有限。

第二，需要在复制完成后做内容校验。rsync有-c参数可以校验，但每次全量比对成本高。我的场景是希望复制过程中顺带计算MD5并记录，下次增量校验时直接比对结果文件。

第三，需要把备份结果集成到发布流水线里。复制完成后的统计信息、失败文件列表、耗时数据，要结构化输出并推送通知。自己写脚本可以完全掌控格式。

第四，需要断点续传和限速。某个大文件复制到一半网络断了，重新跑一遍得浪费很多时间。自研可以做到按块续传，复制期间也可以动态控制速度，避免影响线上服务。

如果你的需求不在这些范围内，用现成工具就好。技术选型的原则是：能用配置解决的别写代码，能写小工具的别上框架。

2.3 技术路线：Python、Java、Go还是Shell

自研方案的语言选择，我结合自己的经验给一个比较主观的判断。Python写起来最快，适合独立的小工具和运维脚本。ThreadPoolExecutor加os.scandir，不到200行就能写出一个够用的多线程复制器。缺点是打包分发稍麻烦，性能上限不及编译型语言，但对文件复制这种IO密集任务，Python足够了。

Java或Spring Boot环境如果已经有现成的后端服务，可以用Java的ExecutorService实现。好处是可以嵌入已有的监控、日志体系，坏处是写起来啰嗦，为了一个复制工具得维护一个编译项目。

Go是这方面比较平衡的选择，goroutine写并发非常自然，编译出来一个二进制，直接扔到服务器就能跑。如果你熟悉Go，用Go写一个多线程复制工具很舒服。但如果要快速改、快速用，Python依然是我的第一推荐。

Shell脚本也能做并发，通过&和wait配合，但控制能力太弱，失败重试、按块续传都不好实现。除非是临时跑一次，否则不建议。

3. 核心实现：一套可直接复用的多线程复制方案

这一节是重点。我写了一个比较完整的Python实现，包含目录扫描、任务队列、线程池、大文件分块复制、进度统计和失败重试逻辑。你不需要照抄，但可以参照这套结构来改自己的版本。

3.1 设计思路：生产者-消费者模型

整个复制流程可以拆成两个阶段：扫描阶段和复制阶段。扫描阶段遍历源目录，把所有需要复制的文件路径和大小记录下来，放到任务列表里。复制阶段由多个线程从任务列表中取任务执行。

这里最关键的决策是使用生产者和消费者模型。扫描线程是生产者，负责把文件路径放进去；复制线程是消费者，负责从队列里取任务去执行。这样做的好处有两个：一是扫描和复制可以重叠进行，扫描线程还没跑完，复制线程已经开始干活了；二是队列天然解决了任务分配不均的问题。比如某个线程处理一个大文件，其他线程可以从队列里取新任务继续跑，而不是干等。

对应的数据结构，Python里可以用queue.Queue。扫描线程put任务，复制线程get任务，队列本身是线程安全的，不用自己加锁。另外一个细节是，扫描阶段记录文件大小，这样后面可以做分块复制，也可以做进度统计。

3.2 目录扫描与任务拆分：别把路径和大小搞丢

扫描是多线程复制的地基，地基没打好，后面跑得再快也是白搭。我见过有人的实现直接用os.walk，每遍历到一个文件就立即丢给线程池执行。这种做法在文件数量少的时候没毛病，但文件数量一多，线程池的任务队列会膨胀到不可控，占用大量内存。

更好的做法是扫描线程先扫描完，把结果整理成列表再分批投递给复制线程。这里有个细节：如果扫描一次全部load到内存，遇到几十万文件的目录，列表本身就能占上百MB内存。所以我一般用带缓冲的队列，扫描线程边扫边放，复制线程边取边做，这样内存占用是稳定的。

任务拆分的思路是这样的：小文件（比如小于50MB）作为一个整体任务，丢给线程池处理时直接复制整个文件。大文件（大于50MB）单独切分成固定大小的块，每个块作为一个独立任务。为什么要切块？因为如果一个线程拿到一个10GB的大文件，其他线程把几万个小文件都做完了，就这个线程还在跑。这个线程跑完后剩下一堆资源闲置，浪费了并发能力。切块之后，多个线程可以同时复制同一个大文件的不同部分，效率明显更高。

python复制import os
import hashlib
import queue
import shutil
import threading
import time
from concurrent.futures import ThreadPoolExecutor
from pathlib import Path

CHUNK_SIZE = 8 * 1024 * 1024  # 8MB 分块
LARGE_FILE_THRESHOLD = 50 * 1024 * 1024  # 50MB 以上视为大文件
BACKUP_ROOT = Path("/data/backup")
SOURCE_ROOT = Path("/data/app/static")


def scan_files(source_root: Path):
    """扫描源目录，yield 出所有文件的路径和大小."""
    for dirpath, dirnames, filenames in os.walk(source_root):
        for name in filenames:
            full_path = Path(dirpath) / name
            try:
                size = full_path.stat().st_size
                yield full_path, size
            except OSError as exc:
                print(f"[scan error] {full_path}: {exc}")


def build_task_list(source_root: Path):
    """生成任务列表，小文件整文件任务，大文件按块切分."""
    tasks = []
    for full_path, size in scan_files(source_root):
        rel_path = full_path.relative_to(source_root)
        target_path = BACKUP_ROOT / rel_path
        if size <= LARGE_FILE_THRESHOLD:
            tasks.append((full_path, target_path, 0, size))
        else:
            offset = 0
            while offset < size:
                read_len = min(CHUNK_SIZE, size - offset)
                tasks.append((full_path, target_path, offset, read_len))
                offset += read_len
    return tasks

task里每一项包含四个值：源文件路径、目标文件路径、起始偏移、读取长度。对于小文件，偏移是0，长度是文件大小，一次复制完。对于大文件，每个块单独成一个任务，带各自的偏移区间。目标路径相同，但写的时候要用的偏移量也记录下来，后面写入时按偏移定位。

3.3 线程池复制逻辑：核心代码

复制阶段我直接用concurrent.futures.ThreadPoolExecutor，它内部维护一个线程池，任务提交后会自动调度到空闲线程上执行。外面再套一层queue来控制任务投递节奏，避免一次性把几十万条任务全塞给线程池导致内存暴涨。

python复制def copy_file_range(src_path: Path, dst_path: Path, offset: int, length: int):
    """复制源文件的 [offset, offset+length) 区间到目标文件对应位置."""
    dst_path.parent.mkdir(parents=True, exist_ok=True)

    # 创建/打开目标文件，保持大小足够
    if offset == 0:
        # 小文件，使用流式复制
        with open(src_path, "rb") as fsrc:
            with open(dst_path, "wb") as fdst:
                shutil.copyfileobj(fsrc, fdst, length=64 * 1024)
        return offset, length, True

    # 大文件分块复制
    mode = "r+b" if dst_path.exists() else "wb"
    with open(src_path, "rb") as fsrc:
        fsrc.seek(offset)
        data = fsrc.read(length)
        with open(dst_path, mode) as fdst:
            fdst.seek(offset)
            fdst.write(data)
    return offset, length, True


def worker(task):
    src_path, dst_path, offset, length = task
    try:
        copy_file_range(src_path, dst_path, offset, length)
        return task, None
    except Exception as exc:
        return task, exc


def run_backup(max_workers=16):
    tasks = build_task_list(SOURCE_ROOT)
    total_tasks = len(tasks)
    completed = 0
    lock = threading.Lock()
    start = time.time()

    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        future_map = {}
        for task in tasks:
            future = executor.submit(worker, task)
            future_map[future] = task

            # 控制已提交未完成任务数量，防止内存膨胀
            if len(future_map) >= max_workers * 2:
                done, _ = concurrent.futures.wait(
                    future_map, return_when=concurrent.futures.FIRST_COMPLETED
                )
                for f in done:
                    task, exc = f.result()
                    if exc is not None:
                        print(f"[error] {task}: {exc}")
                    with lock:
                        completed += 1
                        if completed % 1000 == 0:
                            elapsed = time.time() - start
                            speed = completed / elapsed if elapsed > 0 else 0
                            print(f"progress: {completed}/{total_tasks}, "
                                  f"speed: {speed:.2f} tasks/s")

    # 处理剩余未完成任务
    for future in concurrent.futures.as_completed(future_map):
        task, exc = future.result()
        if exc is not None:
            print(f"[error] {task}: {exc}")
        with lock:
            completed += 1

    elapsed = time.time() - start
    print(f"done: {completed}/{total_tasks}, elapsed: {elapsed:.2f}s")

需要说明一点：分块写入那里，目标文件第一次偏移为0时，用wb模式会创建一个全新文件，大小等于源文件。但多个线程都要写同一个大文件，第一个块创建文件，后面的块需要以r+b模式打开并seek到对应偏移写入。这个逻辑在copy_file_range中通过判断offset是否为0来处理。

不过实际生产环境我建议大文件分块用独立的临时文件，全部写完后合并，而不是多个线程同时写同一个文件。因为多个线程同时写同一个目标文件，会在文件系统层产生大量随机写，反而可能拖慢速度。我当时为了简单先做了直接并发写，后来发现这种方式在机械硬盘上性能糟糕，在SSD上倒是影响不大。如果你的目标盘是机械硬盘，大文件还是老老实实单线程复制比较靠谱。

3.4 别忘了做进度监控和日志

备份最怕的就是跑了一半不知道进度，更怕失败后找不到原因。所以在脚本里加上进度统计和错误日志非常值得，成本低，收益高。

进度这块，我在run_backup里加了completed计数和耗时统计，每1000个任务打印一次速度。如果你希望更直观的进度条，可以用tqdm库包一层，几行代码就能看到百分比和实时速度。不过在生产环境建议还是写结构化日志，方便后续接入日志平台。

python复制import logging

logging.basicConfig(
    filename="backup.log",
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)

# 在worker里记录错误
def worker(task):
    src_path, dst_path, offset, length = task
    try:
        copy_file_range(src_path, dst_path, offset, length)
        return task, None
    except Exception as exc:
        logging.error("copy failed: src=%s dst=%s offset=%d length=%d error=%s",
                      src_path, dst_path, offset, length, exc)
        return task, exc

日志里不光要记录失败的文件，还要带上任务的偏移和长度信息，这样排查时能定位到是哪个块失败。另外，我建议每次备份开始和结束时各写一条日志，包含源目录、目标目录、文件数量、总耗时、成功数和失败数。这个习惯帮过我很多次，尤其是线上问题排查时，拿日志一问一个准。

3.5 断点续传：进阶但不复杂

断点续传是自研方案一个很大的加分项。思路是：在目标目录下生成一个标记文件，记录已经成功复制的文件和对应的块。下次执行时，读取标记文件，跳过已完成的部分。这样一来，网络中断或程序崩溃后重新跑，不需要从头再来。

实现上可以用一个简单的文本文件，每行记录一条任务的索引或路径。但频繁写标记文件会影响性能，所以一般是固定间隔写一次，比如每完成500个任务或者每5秒写一次。进度统计里保留“上次已完成”的数据，新任务列表构建的时候和它做差集就行。

如果觉得这个功能自己实现比较麻烦，另一个思路是直接用rsync的断点续传能力，然后外面套并发控制。但这样又回到“多种约束拼接”的老路上。看你的实际需求，如果备份链路稳定，断点续传优先级不高；如果是跨公网传输，强烈建议做，能省很多时间。

4. 参数调优与实际效果：线程数、分块大小、队列深度

代码写好了，还要调参数。这一步很关键，同样的代码，线程数设置不同，效果天差地别。网上很多人说开64线程、开128线程，实际效果好不好，必须结合自己的磁盘和网络条件来测。我给不出一个万能数字，但可以给出测的方法和大致方向。

4.1 线程数怎么定：从“并发上限”的角度算

先理解一个概念：每个IO设备都有它的并发上限。机械硬盘的并发能力很弱，因为磁头只有一个，同时发起太多随机读写反而导致寻道次数暴增。SSD的并发能力强很多，原生支持并行读写。网络传输的并发上限取决于带宽和延迟，带宽越大、延迟越高，需要越多的并发才能打满。

所以设置线程数前，先确认自己的硬件情况：

• 源盘是机械硬盘还是SSD？
• 目标盘是机械硬盘还是SSD？
• 是本地复制还是跨网络传输？

如果两端都是SSD，线程数可以大方一点，16到32都很安全。如果是机械硬盘，建议从4开始测，然后逐步往上加，找到拐点。跨网络传输的话，我一般先用iperf测一下带宽，然后根据带宽和平均文件大小估算需要多少并发能把带宽打满。

有个经验公式可以参考：并发线程数 = 目标带宽（MB/s） / 单个文件的平均传输速度（MB/s）。比如带宽100MB/s，平均每个文件传输速度2MB/s，那大概需要50个并发才能吃满带宽。注意这里的“平均文件传输速度”包含了打开、关闭、网络往返等开销，不是一个纯网速概念。

4.2 线程数测试记录：从4线程到64线程的对比

我做了组测试，条件是本地SSD到局域网另一台SSD，传输约3万个文件、总大小8.5GB。以下是耗时数据：

从8线程到16线程，吞吐从44.7提升到66.4，收益依然可观。16到32，从66.4到72.0，提升就不明显了。64线程时耗时反而多了3秒，这就是并发超限后调度开销变大的表现。

这个测试结果说明：16线程左右是这台机器的甜点。如果是机械硬盘到机械硬盘，甜点大概在4到8之间。我建议你根据自己环境跑一组对比，找出拐点。

4.3 分块大小对大文件复制的影响

分块大小对大文件复制影响也很大。块太小，比如1MB，会导致IO请求次数暴增，网络和磁盘都要处理大量小任务，效率低下。块太大，比如64MB，会减少单个大文件的并发度——文件只有2GB，切成32块，最多只能有32个线程在并发写它，如果线程池有64个线程，一半线程在干别的任务才能打满。

我测试下来，8MB到16MB是大多数环境下比较合适的值。8MB的块在局域网内几乎能打满千兆带宽，在SSD上也足够让队列始终保持忙碌。如果是万兆网络或者本地高速盘，可以尝试32MB往上加，但要观察内存占用。因为每个块都会在内存里保留数据再写入，8MB块在64线程下最多占用512MB内存，还是可以接受的。

另外，分块复制天然支持按块校验。块写入完成后可以计算块的MD5，和源文件对应块的MD5比对。代价是每个块要多读一遍源数据（校验时读一下），但这个成本在大型备份里是可以接受的。如果追求速度不要校验，跳过这步即可。

4.4 队列深度对内存和稳定性的影响

在3.3节代码里，我用future_map来控制已提交未完成任务的数量，让它不超过max_workers的两倍。这个参数直接影响内存占用和稳定性。

如果一次性提交全部几十万个任务给线程池，线程池内部会创建一个很大的等待队列。每个任务在Python里是一个tuple，记录路径和偏移，40万个任务大概能占几十MB到上百MB内存。服务器内存紧张的情况下，可能会触发OOM。更糟的是，如果线程池内部队列满了，submit操作会阻塞，导致扫描线程和主线程卡住，行为难以预测。

控制未完成任务的数量的另一个好处是：可以平滑地处理错误。每个任务完成时都有机会检查异常，并把失败任务记录到日志，而不是等到最后统一处理。对于备份这种需要稳定性的场景，宁可慢一点，也要让整个流程可观测、可控制。

5. 实际使用中踩过的坑：乱序、校验、限速与平台差异

多线程复制方案跑通容易，跑好很难。我在实际使用中踩了不少坑，这里挑几个典型问题分享出来，希望能帮你少走弯路。

5.1 并发写同一个目标文件：看起来没问题，实际很糟糕

最开始实现大文件分块复制时，我直接让多个线程各自打开同一个目标文件，用r+b模式seek到自己的偏移去写。小文件数量多时没发现异常，但测一个4GB的大文件时发现速度大幅下降，有些块写完后内容还是错的。

排查后发现两个问题。第一，多个线程同时写同一个文件会产生大量文件锁竞争，SSD上还能接受，机械硬盘上性能直接崩掉。第二，Python的open和write并不是对大文件并发写友好的模式，尤其当不同线程交替seek时，文件偏移的定位会产生竞态。虽然理论上每次seek后write是原子的，但操作系统层面文件锁和缓存同步的开销非常大。

最终的解决方案很简单：大文件不要分块并发写同一个文件，而是分成临时文件，全部完成后按顺序合并。每个线程负责下载/复制一个独立的临时文件分片，写完后由主线程按偏移拼接。这样每个线程写的是不同文件，完全无冲突。合并时用二进制模式按偏移写入一个大文件，一次写完，速度很快。

5.2 校验机制：别让备份变成“看起来成功”的假象

备份最大的风险不是慢，而是复制完成后才发现文件损坏。我中途遇到过源文件在复制过程中被写入导致大小变化的情况，还有网络闪断导致文件截断但进程没报错的情况。这些故障单看复制日志根本发现不了，必须靠校验兜底。

最基本的校验是按大小比对，源文件大小和目标文件大小不一致就认为失败。这个极低成本，建议必须做。中等成本的是按文件字节数统计校验，比如复制完成后重新读取目标文件，统计总字节数是否等于源文件。最可靠的是MD5或SHA256全量校验，但开销大，时间上几乎等于再读一遍所有数据。

我的建议是分场景：如果带宽充裕、时间压力不大，就做全量MD5校验；如果是高峰期备份，先做大小校验，然后抽样做MD5，比如每100个文件抽1个。另外，大文件分块复制天然适合增量校验，每个块完成后单独计算该块的MD5，和目标文件对应块的MD5进行比对。这样校验成本被分摊到复制过程中，不会额外增加读源文件的开销。

5.3 备份期间的IO抢占：别把线上服务拖垮

多线程复制把磁盘和网络跑满，对备份任务来说是好事，但对同一台机器上运行的其他服务是灾难。我曾经在备份大目录时直接把线上应用所在磁盘的IO打满了，导致接口响应从几十毫秒变成几秒，被同事吐槽了一下午。

解决思路有两个，一是限速，二是低优先级调度。限速方面，可以在每个线程的复制循环里增加一个限速判断，比如一个线程每秒最多复制N MB，所有线程累加就是总限速。低优先级调度方面，Linux下可以用ionice给备份进程设置idle等级，让系统在磁盘空闲时再为备份分配IO资源；Windows下也可以用进程优先级来缓解。

我实际采用的方案是错峰备份加限速。备份任务放在业务低峰期执行，同时设置一个总带宽上限，比如网卡带宽的60%。这样备份虽然慢一点，但不会影响在线业务。多线程提速的意义是让备份在有限资源下尽可能快，而不是把整台机器的资源都吃光。

5.4 平台差异：Windows的路径和文件占用问题

这个方案最终是部署在Linux服务器上的，但开发时有一版在Windows上测试，踩了不少平台相关的坑。

Windows的路径长度限制相当坑。默认情况下，路径超过260个字符的操作会直接报错。文件目录层级深、文件名长的场景，在Windows上跑备份经常会遇到这问题。绕过方案是使用\?\前缀的扩展长度路径语法，Python里可以用pathlib配合extended-path模式，或者在复制前对路径做短化映射。另外Windows下文件被占用会返回PermissionError，这需要捕获后重试，重试几次仍失败就记日志跳过。

Linux下也有自己的坑，比如符号链接的处理。os.walk默认不会跟随符号链接目录，但会把符号链接本身当作文件处理。如果直接复制一个符号链接，复制过来的是一个指向原路径的链接，不是链接指向的内容。大多数备份场景中符号链接需要保留，但如果目标文件系统不支持符号链接（比如Windows共享目录），就会出错。处理方式是扫描时判断文件类型，符号链接单独记录，复制时先创建目标文件的符号链接，或者选择跟随链接复制实际内容。

5.5 失败重试策略：该重试的别放过，该跳过的别死磕

多线程复制中文件出错是常态，错误处理策略决定了整个备份的鲁棒性。最傻的做法是遇到错误就整个任务失败退出，最灵活的做法是每个文件都有独立的重试策略。

我的做法是失败任务最多重试3次，每次间隔时间递增（1秒、2秒、4秒），这是考虑到网络闪断或文件暂时被占用可能很快就会恢复。如果3次之后还是失败，就把任务写到fail_list.txt，同时继续处理其他文件。备份结束后统一查看fail_list，决定是人工介入还是手动补传。

一个容易被忽略的细节是：失败任务的判定不能只看有没有抛异常。我遇到过源文件很大，复制到一半源文件被删除导致读取失败的情况；也遇到过目标盘空间满但写入返回成功的情况（少见）。所以即使代码没抛异常，也要校验复制后目标文件的大小是否和源文件一致。不用每次都全量校验，但大小不一致这个事故是必须防的。

写在后头：一点经验和后续可扩展的方向

这套多线程复制方案在我这边已经跑了将近半年，累计备份了约30TB数据，总体算是稳定。最大的感受是：多线程确实能解决问题，但它不是银弹。文件数量多、网络延迟高的情况下提升非常明显，但要先想清楚自己的瓶颈在哪，再把并发参数调好，否则容易事倍功半。

如果你准备在自己的项目里落地，建议从5.2节说的校验机制开始做。备份这行，慢一点可以忍受，数据坏了不可接受。把校验、日志、错误重试这三个基础设施做好之后，再考虑上多线程、分块这些性能手段，顺序不能反。

后续我觉得这个方案还有两个可以扩展的方向。一个是接入对象存储作为备份目标，这样源目录直接上传到S3或OSS，本地的并发模型略有调整，但整体思路不变。另一个是做成守护进程模式，定时启动备份任务，备份结果推送到企业微信或钉钉，这样就不用手动跑脚本了。如果你有类似的场景，顺着这个思路往下做就行。