简介：Unstoppable Copier v4.0是一款面向普通用户与数据恢复爱好者的系统工具，专注于从损坏的光盘、软盘或硬盘中逐字节抢救文件，即使遇到坏道、读取超时或分区表被误删也能最大限度找回数据；程序支持通配符指定目录修复，还可当作常规文件复制工具使用。资源包以zip格式压缩，共3个文件，包含主程序exe、使用说明htm与说明文本txt，整体仅86KB，体积小巧且无需安装，解压后即可运行。目前已有328人学习下载，适合需要应急恢复或想了解底层数据读取逻辑的用户。通过该工具，读者可拿到可直接运行的修复程序及配套说明文档，从说明中理解其逐字节读取、遇难读数据自动填充空白并继续的机制，从而在数据丢失时快速应对，也可将其用于日常文件复制与备份场景。
1. Unstoppable Copier v4.0 是什么：它凭什么敢说“停不下来”
某次做模拟项目X的数据迁移，源盘是一块用了六年的仓库盘，32 万个小文件、CAD 图纸、邮件存档和构建缓存混在一起。普通复制工具跑到 63% 卡在一个文件上，弹窗反复问“是否重试”，一晚上过去整个任务进程归零。后来换成 Unstoppable Copier v4.0：读不过去的文件按规则跳过、计入报告，其余文件继续往目标盘搬，天亮时任务跑完，报告里一行行列清楚哪些文件被跳过、为什么被跳过。下面不展开理论演示，就聊这个工具到底怎么工作、参数怎么调、坑在哪里，以及复制完怎么确认数据真的全了。
适合谁：经常做磁盘更换、老旧介质抢救、大目录备份、从故障盘往外捞数据的研发和运维。新手照着第三节能跑通第一次复制，老手看第二和第四节能少踩几个折腾一宿的坑。
2. Unstoppable 的容错核心：失败分类、遍历策略与校验开关
Unstoppable 这个名字的重点不在“快”，而在“不因单个文件失败就终止整个任务”。要做到这一点，工具必须在复制前想清楚一件事：错误来了，哪些该跳过，哪些该停。普通复制工具把“一个文件读不出来”当成“整个任务失败”的信号，于是弹窗、等待、终止；Unstoppable Copier v4.0 的做法相反，它会先把错误分类，再按类别执行对应策略。
2.1 先分清“可跳过”和“必须停”：错误分类模型
v4.0 的错误决策本质上是一棵很小的树：源端读失败，跳过并记录；目标端写失败，停下；文件被占用或权限不足，先重试，重试次数用完再按配置跳过或询问。这句话听起来简单，但几乎所有“翻车”都源于没有真正理解这个分类。
我用一段简化代码模拟这个决策逻辑，方便你在本地把“策略”先跑明白：
# error_decision.py 模拟 v4.0 决策树的简化版本 import errno def decide(err, retries_left): # 源端读失败：坏道、文件在扫描后被删除 if isinstance(err, OSError) and err.errno in (errno.EIO, errno.ENOENT): return "skip" # 跳过该文件，记录原因，继续下一个 # 目标盘空间不足：这是“必须停”的典型情况 if isinstance(err, OSError) and err.errno == errno.ENOSPC: return "abort" # 整个任务停止，不值得逐个跳过 # 文件被占用或权限不足：先重试，重试次数用完再跳过 if isinstance(err, OSError) and err.errno in (errno.EBUSY, errno.EPERM): return "retry" if retries_left > 0 else "skip" return "abort" # 未知错误，保守起见停下来逻辑说明：EIO对应源端 I/O 错误，常见于坏道；ENOENT对应文件在扫描后被其他进程清理；ENOSPC是目标盘写满，遇到这个必须停，否则会造成大量半截文件；EBUSY和EPERM分别表示文件被占用和权限拒绝，这两类适合重试。
参数说明：retries_left对应 v4.0 参数面板里的“Retry attempts”。我一般把它设成 2，而不是默认的“一次失败就跳过”。重试次数设太高，一个被锁死的文件可能拖住整个任务十几分钟；设成 2 既能容忍临时占用，又不会让单个文件成为瓶颈。
这个模型的收益在于：报告里的“跳过”不再是一个笼统的失败列表，而是分类后的结果。你要做的不是看到一堆跳过就重新跑一遍，而是按类别决定下一步。
2.2 先扫描后复制：目录树遍历与共享读打开
批量复制还有一个隐蔽的坑：源目录在复制期间可能持续变化。v4.0 的常见做法是先对源目录做一次完整扫描，生成文件清单，再按清单排队复制。这带来的现象就是任务一开始会有一个“Scanning”阶段，目录里文件越多，这个阶段越长。我见过有人以为它卡死，其实它在枚举文件、收集大小和时间戳。
当源目录有几十万个小文件时，扫描阶段可能持续好几分钟，这属于正常现象，不是死循环。注意观察界面上的文件计数是否在增长，如果计数一直不变，才要考虑是不是源盘响应太慢。机械盘在大量读取小文件时本身就会有 100% 占用率的阶段，扫描慢不代表工具坏了。
文件打开方式上，v4.0 这类容错复制工具有一个关键习惯：以“允许共享读”的方式打开源文件。这意味着即使某个文件正被其他进程打开着，只要对方没有独占锁，它就能把内容读出来。这对日志文件、数据库临时文件很友好。但要注意边界：如果文件正被写入，读出的是一个不稳定快照，甚至可能拿到 0 字节，这不代表文件损坏，只是它不适合被冷复制。
我一般会在任务开始前把关键应用的服务停掉，或者先做一次“冷复制”，再回来处理动态文件。没有哪个纯软件复制工具能保证“正在写入的文件复制出来和最终落盘完全一致”，所以别把这个期望压在一个复制工具上。
2.3 校验开关：什么时候值得多读一遍
Unstoppable Copier 的“复制后校验”跟很多人的直觉不一样：它不是对源和目标做哈希对比，而是逐字节从源再读一遍、从目标再读一遍，然后比较两边读出的内容。代价是校验一遍等于复制一遍，甚至更慢。
所以校验开关要按场景决定。坏道盘救援、老硬盘搬迁这类场景，开启校验是值得的：它能告诉你“跳过”之外还有没有文件被复制成功了但内容对不上。普通新盘之间的拷贝、海量小文件备份，我建议关闭全局校验，否则 10 万个小文件能让校验阶段跑一整夜。
如果源盘确实有问题，又不想整盘校验，折中做法是只对关键子目录开启校验。工具通常支持按目录配置校验策略，把数据库备份、设计图纸这类高价值目录单独开。其他目录只做复制，靠后面第五节的抽样哈希兜底。
3. 用 Unstoppable Copier v4.0 完整备份：步骤、参数与边界
这节解决“怎么做”的问题。我按自己实际使用的顺序来：先跑前置检查脚本，再走一遍 GUI 最小流程，然后解释关键参数，最后说明什么时候不该用它。
3.1 复制前先跑一个 precheck 脚本：文件数、总量、长路径
不要一开始就拖目录，先花一分钟确认源目录到底有多少文件、多大体积、有没有路径过长的文件。下面这个脚本我经常在复制前跑：
# precheck.py 复制前检查：文件数、总体积、长路径 import os import sys def scan(src): count = 0 total = 0 long_paths = [] for root, _, names in os.walk(src): for name in names: p = os.path.join(root, name) try: st = os.lstat(p) except OSError: continue count += 1 total += st.st_size if len(p) > 240: long_paths.append(p) return count, total, long_paths if __name__ == "__main__": src = sys.argv[1] count, total, long_paths = scan(src) print(f"files: {count}") print(f"size : {total / (1024**3):.2f} GiB") print(f"paths longer than 240: {len(long_paths)}") for p in long_paths[:10]: print(p)逻辑说明：os.walk递归遍历源目录，os.lstat只读元数据，不会触发文件内容读取，所以扫描速度远快于真实复制。long_paths收集超过 240 字符的路径，这里特意用 240 而不是 260，因为目标盘前缀还会再加一段路径长度。
参数说明：如果你复制的是 100 万文件以上的超大目录，这个脚本本身也需要跑一阵，建议把它放到后台执行。目标盘可用空间要和size对比，我的习惯是目标盘剩余空间至少是源数据量的 1.1 倍。长路径数量不为 0 时，先处理长路径再复制，否则它们很可能在扫描阶段就被漏掉，后面详细说。
3.2 最小 GUI 流程：从拖入源目录到生成报告
前置检查通过后，打开 Unstoppable Copier v4.0，按下面顺序走一遍：
- 把源目录拖进 Source 输入框。
- Destination 选择目标盘上的一个空目录，最好选独立的数据盘，而不是系统盘根目录。
- 错误处理策略选“Skip all”，不要选“Ask me”。“Ask me”会让任务在第一个失败文件上停下来等你点确定，适合小规模复制，不适合无人值守。
- 复制后校验先关闭，等任务跑完后再针对关键目录单独校验。
- 点 Start Copying，等待扫描阶段结束，再等待复制阶段完成。
到这一步，你已经完成了一次无人值守的容错复制。任务结束后会生成一份报告，包含每个跳过文件和失败原因。别急着删源盘，先把报告过一遍。
3.3 关键参数怎么设：重试、延迟、过滤和覆盖
v4.0 参数面板里最影响结果的是这四个：
| 参数 | 作用 | 我一般给的值 |
|---|---|---|
| Retry attempts | 文件打开失败时重试几次 | 2 次 |
| Retry delay | 每次重试之间的等待时间 | 200ms |
| Overwrite mode | 遇到目标已存在同名文件时怎么处理 | 第一次复制选“跳过已有文件” |
| 文件过滤 | 排除不想复制的目录或扩展名 | 排除临时文件、缓存目录、node_modules |
重试延迟 200ms 是为机械盘准备的。如果是网络盘或设备响应慢，可以调到 500ms 到 1s。反过来，如果源盘本身已经很慢，重试次数设太高会让任务卡在一个文件上很久，建议 2 次封顶。
过滤规则比想象中重要。很多仓库盘里混着*.tmp、编译缓存、旧的日志文件，这些复制过去既浪费时间又占用空间。v4.0 支持按文件名或路径模式过滤，我会把这类目录排除掉。
覆盖模式我强调一下：第一次复制时选“跳过已有文件”，这样如果任务因为某种原因中断，第二次重跑不会把已经复制好的文件再覆盖一遍。只有确定源文件更新过，才改选覆盖。
3.4 与 robocopy、rsync 的正确边界：什么时候别用
Unstoppable Copier 的优势是容错、GUI 可视、报告直观，它更适合“把一份又大又脏的目录抢救出来”。但它的定位不是通用同步工具，下面这些场景我不建议用它：
| 工具 | 优势 | 适用场景 | 不适合的场景 |
|---|---|---|---|
| Unstoppable Copier | 容错复制、错误跳过、报告直观 | 故障盘搬迁、老旧介质抢救 | 定时增量同步、跨网络复制 |
| robocopy | 增量、支持 ACL、可脚本化 | 本地增量备份、权限保留 | 遇到坏道可能反复重试而卡住 |
| rsync | 跨平台、增量、网络同步 | 跨服务器同步、定时备份 | 对坏道盘的跳过粒度不够细 |
如果你需要的是每天定时把新文件同步过去，或者完整保留权限和 ACL，请改用 robocopy 或 rsync 这类工具。Unstoppable Copier 的主场是一次性任务：把数据从“随时可能坏”的盘里搬出来，搬的时候不因一两个坏文件放弃全部。理解这个边界，你就不会在错误的场景里骂它不好用。
4. 避坑：Unstoppable Copier v4.0 的 5 个翻车现场与排查
工具本身容错强，不代表用法不会错。以下 5 个问题都是我身边真实遇到过的场景，按现象、原因、解决三步整理。
4.1 一晚上重试同一个文件？重试次数和延迟要按场景调
现象：任务卡在 70% 不动，界面显示某个文件正在重试，日志里反复出现同一个路径。
原因：最常见是把错误处理策略留在了“Ask me”，任务停在弹窗等待人工确认；其次是重试次数设得太高，比如 10 次、每次间隔 1 秒，一个被锁定的文件就能拖住任务几分钟。
解决：无人值守时把错误策略改成“Skip all”，重试次数控制在 2-3 次，重试延迟 200ms。如果某个文件特别重要，等任务结束后单独复制它，而不是让整个任务等它。
4.2 跳过文件太多？先看报告的错误类型，别急着重来
现象：复制完成，报告显示跳过几千个文件，第一反应是“这任务失败了”，直接从头再跑一遍。
原因：跳过的原因可能不是坏道，而是权限不足。比如源目录里有一些系统文件、临时锁定文件，它们被跳过是预期行为。
解决：先把报告按错误类型分组。如果“权限不足”占大多数，补一轮带管理员权限的复制即可；只有“源端读取失败”占大头，才需要怀疑介质问题。不看原因就重跑，等于为几百个无关文件再做一次全量 I/O，浪费时间不说，还可能让本来健康的盘承受不必要的读取压力。
4.3 长路径文件在扫描阶段就被漏掉，报告里也没有记录
现象：复制完成后打开目标目录，发现缺了一个小目录，但报告里没有任何跳过或失败记录。
原因：有些文件系统的路径长度上限在 260 字符左右。路径超长时，工具在扫描阶段可能把它视为“不可枚举”，它既进不了复制队列，也不会出现在跳过列表里。这类文件在报告里是缺失的，只靠看报告根本发现不了。
解决：用 3.2 节的 precheck 脚本提前抓出路径超长文件。处理方法是把超长路径的父目录重命名缩短，或者用符号链接把祖先目录映射到一个短路径下。处理完再启动 Unstoppable Copier，不要依赖事后报告判断完整性。
4.4 开完全量校验，海量小文件场景慢到不可用
现象：复制本身只花了 2 小时，开启“复制后校验”之后跑了一整夜还在校验，速度低到不可接受。
原因：逐字节校验需要从源和目标各读一遍，等于 2 倍 I/O。再加上小文件打开文件的次数开销，10 万个小文件场景下校验时常确实可能接近复制时长。
解决：大目录备份默认关闭全局校验，只对关键子目录单独开。如果你不确定数据完整性，用第五节的抽样哈希来验证，既省时间又能覆盖大概率风险。
4.5 正在写入的日志文件复制回来是 0 字节，但报告没有任何异常
现象：复制完发现某些.log文件大小为 0，但报告显示这些文件“复制成功”。
原因：复制那一刻，另一个进程正以写模式打开这些日志文件。工具以共享读方式打开它们，看到的是一个空文件或半截文件，然后原样复制了出去。这不是漏报，是“正在写入的文件本来就不适合冷复制”。
解决：复制前先把相关应用停掉，或者单独处理动态文件。日志文件可以先复制一遍存量，等应用停止后再补一遍增量。不要把实时性要求押在复制工具上，它保证的是“读到什么复制什么”，不是“复制出来的和最终写入一致”。
5. 用“三次对比法”验证一次 Unstoppable Copier 复制：文件数、总量、抽样哈希
复制结束、报告也看了，别急着删源盘。我收尾的习惯是做三次对比，每次几分钟，能挡住绝大部分“悄悄丢文件”的事故。
第一次对比：报告与源目录核对。把报告里的跳过和失败项逐个过一遍，确认每个文件都有合理解释。如果发现某个关键文件在跳过列表里，立刻单独处理它，不要等整体重跑。
第二次对比：文件数、总量与源目标。用 3.2 节的 precheck 脚本分别统计源目录和目标目录的文件数和总字节数。目标数应等于“源数减去报告跳过的数量”，总量同理。如果差额对不上，说明存在扫描阶段就漏掉的文件，这类文件在报告里是隐形的，只能靠数值对比暴露。
第三次对比：抽样哈希。分目录分层随机抽 50 到 200 个文件，对源和目标各算一次 SHA-256。重点抽取两种文件：报告里出现过重试的文件，以及业务上不可再生的重要文件。脚本如下：
# verify_sample.py 抽样校验 import os import sys import random import hashlib def sha256(p): h = hashlib.sha256() with open(p, "rb") as f: for chunk in iter(lambda: f.read(1 << 20), b""): h.update(chunk) return h.hexdigest() source = sys.argv[1] target = sys.argv[2] n = int(sys.argv[3]) random.seed(2025) candidates = [] for root, _, files in os.walk(source): for f in files: candidates.append(os.path.relpath(os.path.join(root, f), source)) sampled = random.sample(candidates, min(n, len(candidates))) bad = 0 for rel in sampled: sp = os.path.join(source, rel) dp = os.path.join(target, rel) if not os.path.exists(dp) or sha256(sp) != sha256(dp): print("MISMATCH", rel) bad += 1 print(f"checked={len(sampled)} mismatched={bad}")逻辑说明：先遍历源目录生成相对路径清单，再用固定随机种子抽样，保证同一目录每次验证结果可复现。sha256分块读取，避免大文件一次性载入内存。目标不存在或哈希不一致都会输出MISMATCH。
参数说明：第三个参数n是抽样数量。文件总数小于 10 万时我抽 100 个，超过 10 万时抽 200 个。如果候选文件几十万，candidates列表会占一些内存，需要更省内存的话改成蓄水池抽样，一次遍历边收集边决定。
这套方法是我吃过亏才养成的习惯。以前复制完只看报告，报告上没失败就收工，后来有一次发现目标目录少了整整一个小目录，报告里完全没有记录。自那以后，不管 Unstoppable Copier v4.0 看起来多顺利，收尾我一定跑一遍文件数对比和抽样哈希，宁可多花十几分钟，也不再让某个目录无声消失。希望帮到你。
本文还有配套的精品资源，点击获取
