使用 Robocopy 和 SMB Multichannel 将 Synology NAS 迁移到 UniFi UNAS Pro 8

# 使用Robocopy、SMB多通道和令人惊讶的性能陷阱将Synology NAS迁移至UniFi UNAS Pro 8 来源：https://www.hanselman.com/blog/migrating-a-synology-nas-to-a-unifi-unas-pro-8-with-robocopy-smb-multichannel-and-surprising-performance-traps 我使用Synology NAS（https://www.hanselman.com/blog/synology-ds1520-is-the-sweet-spot-for-a-home-nas-and-a-private-cloud）已很长时间（https://www.hanselman.com/blog/a-basic-noncloudbased-personal-backup-strategy），最近开始将其内容迁移至新的Ubiquiti UniFi UNAS Pro 8（https://store.ui.com/us/en/category/network-storage）。这本该是个相当枯燥的操作——两台设备都支持SMB协议，我拥有高速网络（近期已升级至万兆内网），而且Windows数十年来一直提供着可靠的文件复制工具。然而，这最终演变成了一整晚重新学习自认为已掌握知识的过程，这也是我撰写此文的原因。 对我而言，这背后还有段历史渊源：早在2007年（天呐！），我曾撰文**"XCopy已过时——Robocopy或XXCopy或SyncBack（https://www.hanselman.com/blog/xcopy-considered-harmful-robocopy-or-xxcopy-or-syncback）"**。当时的观点是：一旦文件数量达到一定规模，资源管理器就不再适用，而Robocopy的优势便凸显出来。我甚至使用了Robocopy的`/Z`可恢复模式，因为在不可靠网络环境中能够继续中断的传输非常实用。 但近二十年后，`/Z`参数竟成了最需移除的选项之一，因为它让整个过程变得异常缓慢。 #### 迁移过程 基础任务很简单。Synology上存在如下共享： ``` \\server\music ``` UNAS上设有对应共享： ``` \\UNAS-Pro-8\music ``` 起初我使用资源管理器进行操作，既因为其便捷性，也因为有时简单方法确实有效。这种状况持续到资源管理器开始对特定文件报错： ``` 请求的操作因文件系统限制无法完成 ``` 我首先怀疑是文件名问题。NAS迁移常会揭示不同文件系统的兼容性差异，而文件名中确实包含括号等特殊符号。 随后这个文件导致迁移失败： ``` \\server\music\Athlete\Tourist\05 Wires.m4p ``` `05 Wires.m4p`文件并无特殊之处，于是我转向Robocopy获取更多信息。它始终在进度达到92%时返回Windows错误665： ``` 92% 新文件 4.3 MB 05 Wires.m4p 错误 665 (0x00000299) 复制文件时 请求的操作因文件系统限制无法完成 ``` 此时问题已从"该文件名有何问题？"转变为"路径中哪个环节拒绝此文件？" 我将文件从Synology复制到本地Windows桌面——成功。随后从Windows复制到UNAS——同样出现文件系统限制错误。 由此可确定：Synology可读取该文件，Windows能存储该文件，而将此文件写入UNAS时出现问题。 #### 再谈备用数据流 NTFS文件除常规无名流（通常被视为文件内容）外，还可包含命名的备用数据流（Alternate Data Streams）。这是Windows文件系统的古老特性，恰好我在2007年讨论`Zone.Identifier`（Windows用其记录下载文件来源）时曾撰文提及（https://www.hanselman.com/blog/removing-security-from-downloaded-powershell-scripts-with-alternative-data-streams）。我甚至在2003年就发表过关于备用数据流的博文（https://www.hanselman.com/blog/emancipation）！Windows可通过`DIR /R`命令显示这些流。 因此我执行： ``` dir /r "%USERPROFILE%\Desktop\05 Wires.m4p" ``` 得到： ``` 11/30/2011 02:17 PM 4,576,368 05 Wires.m4p 360,456 05 Wires.m4p:01APIC_03.jpg:$DATA ``` 答案在此。除正常的4.5MB音乐文件外，还存在约360KB的命名数据流`01APIC_03.jpg`。 这也解释了为何进度会在92%失败：Robocopy成功复制了文件主体内容后，遇到了附加流。看似在普通`.m4p`文件中部发生的错误，实则是Windows尝试处理附加文件系统数据时出现的。 Robocopy对此情况有专门支持。微软文档将`X`列为`/COPY`标志选项之一，表示"跳过备用数据流"。因此： ``` /COPY:DATX ``` 意为复制文件的数据、属性和时间戳，但不复制备用流。`/DCOPY:DATX`将相同行为应用于目录。我重新尝试该文件： ``` robocopy "\\server\music\Athlete\Tourist" "\\UNAS-Pro-8\music\Athlete\Tourist" "05 Wires.m4p" /R:0 /W:0 /COPY:DATX /DCOPY:DATX /V ``` 成功完成。重要区别在于：`DATX`不会移除MP3、M4A、M4P、JPEG或其他文件格式内部存储的元数据。它仅指示Robocopy不复制文件关联的独立文件系统流。对我而言，新NAS无需保留这些额外流。 #### 复制成功但速度缓慢 明确备用数据流问题后，我使用常规Robocopy命令启动大规模迁移： ``` robocopy "\\server\music" "\\UNAS-Pro-8\music" /E /Z /MT:16 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:"%USERPROFILE%\Desktop\synology-to-unas.log" ``` 命令运行，但性能起伏剧烈。有时能达到数百兆比特每秒，随后急剧下降。小文件可能长时间停滞。我开始怀疑是缓冲机制、磁盘速度、校验计算、UNAS的SMB行为所致，或是Synology已至性能极限。 于是进入"尝试随机变量（二分法）"阶段。我减少线程数，尝试单线程——均无效。随后移除了`/Z`参数。 微软Robocopy文档将`/Z`描述为可恢复模式，允许中断的文件续传而非从零开始。我忘记的是：微软当前的迁移指南特别警示应谨慎使用`/Z`，因实现续传所需的额外日志会显著降低复制性能。 最终成功迁移音乐库使用的是： ``` robocopy "\\server\music" "\\UNAS-Pro-8\music" /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:"%USERPROFILE%\Desktop\synology-to-unas-DATX.log" ``` 该次运行摘要： ``` 总计 已复制 跳过 不匹配 失败 文件 : 15940 6991 8949 0 0 字节 : 70.907 g 47.917 g 22.989 g 0 0 速度 : 187,185,171 字节/秒 ``` 这次复制近48GB剩余数据的过程平均速度约187MB/秒，无失败文件。 这并非严格控制的基准测试（我未保持其他变量一致），故不敢断言`/Z`是早期减速的全部原因。但实际差异足够显著，`/Z`不再是我在局域网迁移命令中自动添加的选项。在稳定本地网络中，我宁愿不添加此参数，仅在真正需要其功能时使用。 #### `/MT`很有用，但适用于特定问题类型 Robocopy的`/MT:n`选项使用多线程执行复制，支持1至128的值。若未指定数值，默认使用8线程。微软迁移指南同时指出：更多线程未必自动加速迁移，建议根据实际负载测试线程数。 当我停止将`/MT:4`理解为"让单个文件速度提升四倍"后，这更容易理解。 想象一个音乐集合包含数千个来源可疑的文件（我开玩笑，是我自己抓轨的）。打开文件、创建目标文件、读写内容、处理元数据、关闭文件都需要操作开销。单线程复制时，网络或存储可能在某操作完成前处于等待状态。同时处理多个文件可使Robocopy有机会重叠这些操作。 对此特定集合，四线程效果显著。十六线程未见明显提升，单线程则性能不足。我不主张将`/MT`变成每条命令必加的魔数，因为包含五万张照片的目录与四个900GB磁盘映像的工作负载截然不同。 需注意日志记录成本。微软建议多线程复制时将Robocopy输出重定向到日志文件，迁移指南使用`/NP`、`/NFL`、`/NDL`等开关，当目标是吞吐量而非观察每个文件名滚动时。 对于不主动监控的迁移，我可能会用： ``` robocopy "\\server\share" "\\UNAS-Pro-8\share" /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /NP /NFL /NDL /LOG:"%USERPROFILE%\Desktop\nas-migration.log" ``` #### 接着遇到大文件问题 后来我开始复制数百GB的大文件。微软将`/J`描述为无缓冲I/O，推荐用于大文件，这看似显然的选项。 但启用`/J`后，NAS间传输显著减速。中间存在Windows机器的好处是可分别测试传输两端。我取一个完全相同的大文件，直接从Synology复制到本地机——速度约250MB/秒，证明Synology完全能高速读取该文件。 随后我在直接从Synology到UNAS的Robocopy命令中移除`/J`： ``` robocopy "\\server\share" "\\UNAS-Pro-8\share" "huge-file.ext" /R:0 /W:0 /COPY:DATX /NP ``` 速度恢复正常。 我认为合理结论并非`/J`不好。微软推荐它用于大文件复制有其理由，且在从本地磁盘到本地磁盘或其他网络配置时它可能正是所需。关键点在于：Windows同时从一个SMB服务器读取并写入另一个SMB服务器时，缓冲I/O在此特定路径表现更佳。 这提醒我们：命令行开关描述行为，而非保证性能提升。`/J`改变I/O模型，`/MT`改变并发性，`/Z`添加续传功能。这些改变是否有利于迁移，取决于系统其他部分。 #### Synology性能超乎预期 数次我归咎于老旧的Synology。这台配备机械硬盘的旧机器，让人轻易假设数百兆比特每秒就是其极限。随后我记起Synology拥有四个千兆以太网接口，且SMB 3支持多通道。我至今惊讶于其出色表现。 SMB多通道允许SMB会话同时使用多条网络路径。微软将其明确记录为聚合可用网络带宽的方法，Synology支持SMB3多通道也是出于同样原因。 Windows可便捷检查活跃通道： ``` Get-SmbMultichannelConnection -ServerName server | Format-Table ServerName,Selected,ClientIpAddress,ServerIpAddress,ClientLinkSpeed,ServerLinkSpeed,CurrentChannels ``` 我的机器报告： ``` ServerName Selected ClientIpAddress ServerIpAddress ClientLinkSpeed ServerLinkSpeed ---------- -------- --------------- --------------- --------------- --------------- server True 192.168.1.45 192.168.1.210 1000000000 1000000000 server True 192.168.1.45 192.168.1.198 1000000000 1000000000 server True 192.168.1.45 192.168.1.197 1000000000 1000000000 server True 192.168.1.45 192.168.1.26 1000000000 1000000000 ``` Synology全部四个千兆以太网接口均参与SMB连接。 我的Windows机现配备2.5GbE适配器（万兆即将到来），快速复制期间从Synology接收速度约250MB/秒。这突然让系统行为不再神秘：SMB多通道使Windows可利用服务器端四条可用路径，因此Synology并未受限于单千兆以太网连接的吞吐量，而PC端的2.5GbE链路反而成为较小的网络管道。 Synology文档在此处对SMB多通道与常规链路聚合做了重要区分：多通道可通过使用多条网络连接提升单个客户端的SMB性能，而传统链路聚合通常关注多客户端与服务的聚合吞吐量。 如前所述，我的Windows机即将配备10GbE适配器，迁移后可进行另一项实验。Synology仍仅有四个千兆以太网接口，聚合网络链路带宽为4Gb/秒，但移除当前2.5GbE客户端瓶颈后，将展现磁盘与Synology本身尚有多大潜力。对于这台我已心理降级为"慢速备份NAS"的老设备，其表现令人惊喜。 #### 我还尝试了rsync 是的，我知道——那rsync呢？你可能会说Windows作为中间环节不必要。Synology可提供rsync，而UniFi Drive可从使用守护进程模式的rsync服务器拉取。Ubiquiti在Drive的备份任务中记录了rsync路径，并要求此类源使用守护进程模式。 在其他实验进行时，我用rsync尝试了单独的电影共享。它有效运行，速度约67MB/秒。但它生成的目录布局带有额外嵌套层级，事后需要清理。 这并非论证rsync总体速度慢，或其目录行为无法正确配置。这仅是此次Synology至UNAS测试中的实际情况。当Robocopy路径达到约187MB/秒并精确保留我所需的UNC共享布局后，我缺乏动力将rsync设为主要迁移机制。 略有趣的结果是，看似间接的路径： ``` Synology -> SMB -> Windows -> SMB -> UNAS ``` 在我的环境中比直接让两台NAS设备使用UniFi Drive暴露的rsync实现传输测试共享快得多。我的猜测是rsync未使用链接的4条1Gbps连接。欢迎在评论区分享你的看法。 #### 最终采用的Robocopy命令 对于包含大量文件的普通共享，我当前会采用以下版本： ``` robocopy "\\server\share" "\\UNAS-Pro-8\share" /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /NP /NFL /NDL /LOG:"%USERPROFILE%\Desktop\nas-migration.log" ``` 各开关的具体功能： ``` /E 复制子目录，包括空目录 /MT:4 允许四个文件复制线程 /R:2 失败复制重试两次 /W:2 重试间隔等待两秒 /COPY:DATX 复制数据、属性和时间戳，但跳过ADS /DCOPY:DATX 对目录应用对应的复制标志 /XJ 排除联接点 /NP 不显示百分比进度 /NFL 不记录每个文件名 /NDL 不记录目录列表 ```