从 Synology 迁移到 UniFi UNAS Pro 8：Robocopy 迁移中的性能陷阱与踩坑记录

我有过群晖NAS对于非常久了最近我开始把它的内容迁移到新的Ubiquiti UniFi UNAS Pro 8.这看起来应该是个相当无聊的行动。两台设备都支持SMB，我有一个快速的网络（最近内部升级到10千兆），Windows几十年来一直有可靠复制文件的工具。

自然地，这变成了一整晚的学习，我以为自己已经知道了，这也是我开博客的原因，哈哈。

对我来说，这里有一段不错的历史，因为回到2007年（天哪！）我写过一篇叫做“XCopy被视为有害——Robocopy、XXCopy或SyncBack.”我当时的观点基本上是，一旦你移动了足够多的文件，资源管理器就不再是移动工具，Robocopy 看起来也变得相当不错。

我甚至用过/ZRobocopy 的可重启模式，因为能够恢复部分传输的文件在不稳定的连接中非常有用。

将近二十年后，/Z结果发现这是我必须移除的最重要部分之一，因为它让整个过程变得非常缓慢。

迁徙

基本工作很简单。我在Synology持有股票，例如：

\\server\music

以及UNAS上的匹配股份：

\\UNAS-Pro-8\music

我最初用的是Explorer，主要是因为它存在，而且有时候简单的事情其实就是简单。直到 Explorer 开始在单个文件上出现错误：

The requested operation could not be completed due to a file system limitation

我第一反应是文件名。NAS迁移充满了发现某一文件系统比其他更宽松的机会，文件名中也带有括号和其他标点符号。

然后这个方法失败了：

\\server\music\Athlete\Tourist\05 Wires.m4p

这并不特别异国情调05 Wires.m4p于是我转向了Robocopy，想了解更多信息。它持续达到92%，并返回了Windows错误665：

92%        New File               4.3 m        05 Wires.m4p
ERROR 665 (0x00000299) Copying File
The requested operation could not be completed due to a file system limitation

此时，有用的问题不再是“这个文件名有什么问题？”而是“路径的哪个部分拒绝了这个文件？”

我把文件从Synology复制到本地Windows桌面。这招奏效了。然后我把本地文件从 Windows 复制到 UNAS，但同样因为文件系统限制失败了。

这样问题就被隔离出来了，Synology可以读取文件，Windows可以存储它，而写入这个特定文件到UNAS时出现了一些问题。

又是替代数据流

NTFS文件可以包含命名的备用数据流，除了我们通常认为的文件内容的普通无名数据流外。这是Windows文件系统的一个旧功能，这正是我在2007年写过的一篇文章讨论时Zone.IdentifierWindows可以利用它来记录下载文件的来源。

我甚至2003年博客中关于替代数据流的文章!!!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.5 MB音乐文件外，还有一个大约360 KB的命名数据流，名为01APIC_03.jpg.

这也解释了奇怪的92%失败率。Robocopy成功访问了文件的主要内容，然后遇到了额外的流。那看起来像是普通人生中某个失败的时刻.m4p实际上，当Windows尝试处理额外的文件系统数据时，文件就已经发生了。

Robocopy 正好支持这种情况。Microsoft文档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上。

复制工作成功了，但速度很慢

一旦了解了ADS问题，我就用一个看起来相当常规的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.

Microsoft的Robocopy文档描述了/Z作为可重启模式，允许中断的文件继续，而不是从零字节重新开始。我忘了，Microsoft当前的迁移指南特别警告了这一点/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"

那次比赛的总结是：

               Total    Copied   Skipped  Mismatch    FAILED
    Files :     15940      6991      8949         0         0
    Bytes :  70.907 g  47.917 g  22.989 g         0         0
   Speed :           187,185,171 Bytes/sec.

所以复制近48GB剩余数据的运行平均速度约为187 MB/秒，且没有文件失败。

这并不是一个受控基准测试，我只改变了一个变量，其他变量保持不变，所以我不会假装这个数字能证明这一点/Z这完全解释了之前的放缓。

然而，实际的差异足够大，/Z不再是我会自动在LAN迁移命令里输入的，仅仅因为可重启性听起来更好。在稳定的局域网络中，我会先不使用它，只有在真正需要语义时才添加。

/MT很有用，但它帮助的是特定类型的问题

Robocopy的/MT:n选项通过多个线程运行副本。它支持1到128的值，默认情况下是八线程/MT该产品没有编号。Microsoft 自己的迁移指南也指出，线程数量增加并不自动意味着迁移速度更快，建议将线程数量与实际工作负载进行比较。

当我不再思考/MT:4比如“让一个文件快四倍”。

想象一下，一个音乐收藏里有成千上万个来源可疑的文件（我只是开玩笑地翻录了它们）。打开文件、创建目标文件、读写其内容、处理元数据以及再次关闭这些工作都涉及。

单线程副本会有一段时间，网络或存储可能会等待其中一个操作完成。同时处理多个文件给了Robocopy机会与这些工作重叠。

对于这个系列，有四条线条非常合适。十六号显然并没有帮上更多忙，一条线也没什么好。我会抗拒转弯/MT变成一个魔法值，这个值属于每个命令行，因为一个包含5万张照片的目录，与四个900 GB的磁盘镜像带来了不同的工作负载。

还有一笔伐木成本值得记住。Microsoft 建议在使用多线程副本时将 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。Microsoft描述/J因为它是无缓冲的I/O，并且推荐用于大文件，所以这似乎是显而易见的尝试选择。

其中/J启用后，NAS间传输速度大幅减慢。中间有一台Windows机器的好处是我可以分别测试这趟旅程的每一半。我拿了一个完全相同的大文件，直接从Synology复制到本地机器。

该系统运行速度大约为250 MB/s，因此Synology完全能够高速读取文件。

然后我把它取出/J来自Synology直接到UNAS Robocopy的指令：

robocopy "\\server\share" "\\UNAS-Pro-8\share" "huge-file.ext" /R:0 /W:0 /COPY:DATX /NP

速度又回来了。

我认为有用的结论不是/J很糟糕。Microsoft 推荐它用于大文件副本是有原因的，而且很可能它正是你在从本地磁盘复制到本地磁盘或在其他网络配置中想要的。

关键在于，Windows同时从一个SMB服务器读取数据，同时写入另一个SMB服务器，在这条特定路径上缓冲I/O表现更好。

这提醒我们，命令行交换机描述的是行为，而非保证性能提升。/J改变I/O模型。/MT改变并发。/Z增加了可重启性。这些变化是否能改善迁移，取决于系统的其他部分。

Synology比我想象的要快

我曾多次将责任归咎于日渐老化的Synology。这是一台老旧的机器，配有旋转磁盘，所以很容易以为它仅剩几百兆比特每秒。然后我想起来，Synology有四个1 GbE接口，SMB 3支持多通道。

我仍然惊讶这方法能这么好用。

SMB多通道允许SMB会话同时使用多条网络路径。Microsoft 专门将此文档用于聚合可用网络带宽，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上的四个1 GbE接口均参与SMB连接。

我的Windows电脑目前有一个2.5 GbE适配器（10GB即将推出），在快速复制过程中，我看到Synology大约有250 MB/秒的速度。这突然让系统的行为不再那么神秘。

Synology的吞吐量并不限于单一千兆以太网连接，因为SMB多通道允许Windows使用四条可用的服务器端路径，而PC上的2.5 GbE链路正逐渐成为更小的网络管道。

群晖的文档在此对中小企业多通道和普通链路聚合做出了重要区分。多通道可以通过使用多个网络连接提升单个客户端的SMB性能，而传统的链路聚合通常强调多个客户端和服务之间的总吞吐量。

就像我说的，我有一个10 GbE的Windows适配器正在路上，迁移后还有另一个实验。Synology仍然只有四个1 GbE接口，总计网络链路为4 Gb/sec，但消除当前2.5 GbE客户端瓶颈后，应该能展示磁盘和Synology本身的传输距离。

对于我已经心里把它归为“慢速备份NAS”的老NAS来说，它的表现出乎意料地好。

我也试过rsync。

是的，我知道，那rsync呢？你是说Windows作为中间人没必要。Synology 可以支持 rsync，UniFi Drive 可以通过守护进程模式从 rsync 服务器拉取数据。

Ubiquiti 在 Drive 的备份任务中记录了 rsync 路径，并要求此类源代码使用守护进程模式。

在其他实验进行期间，我尝试用rsync单独分享电影。结果成功了，我看到大约67 MB/秒。它还给了我一个目的地布局，带有一些额外的目录嵌套，之后需要清理。

这并不是说rsync本身很慢，也不是说它的目录行为无法正确配置。这正是这次Synology到UNAS测试中发生的情况。当Robocopy路径达到大约187 MB/sec，并且完全符合我想要的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           Copy subdirectories, including empty ones
/MT:4        Allow four file-copy threads
/R:2         Retry a failed copy twice
/W:2         Wait two seconds between retries
/COPY:DATX   Copy data, attributes and timestamps, but skip ADS
/DCOPY:DATX  Apply the corresponding directory copy flags
/XJ          Exclude junction points
/NP          Don't print percentage progress
/NFL         Don't log every filename
/NDL         Don't log every directory
/LOG         Write the useful output to a file

我故意没有/Z就在里面。我也不会自动添加/J;对于负载非常大的文件，我会先测试带和不带同一个传输，再决定是否进行多TB运行。

该/MT价值同样是经验性的。四个线程对于这个Synology和这种文件组合来说效果非常好，但我会尝试用1、4、8或其他合理的数字对应真实数据的代表性切片，而不是假设最大线程数是最好的。

检查结果

对于我足够在意并能证明目标字节与源完全相同的文件，PowerShellGet-FileHash是一个方便的最终检查：

Get-FileHash "\\server\share\huge-file.ext" -Algorithm SHA256
Get-FileHash "\\UNAS-Pro-8\share\huge-file.ext" -Algorithm SHA256

Get-FileHash默认使用 SHA-256，如果 SHA-256 值匹配，则两个输入产生相同的消化。对于庞大文件，这需要在两端重新读取整个文件，所以我不太可能对音乐收藏中的每首歌都进行哈希，但这是迁移后验证那些特别有价值、数百GB文件的简单方法。

在责怪NAS之前，有几点我会先检查

这次迁移之所以有趣，是因为这些症状可能支持多种合理的解释。UNAS有了新的RAID阵列，Synology很老旧，Windows作为SMB客户端双向运行，文件来自多年不同应用，Robocopy的交换机足够多，几乎让任何命令行看起来都很权威。

当文件失败时，我先从Synology复制到本地，再本地复制到UNAS，这暴露了目标端的ADS问题。当大文件慢时，我会把同一个文件复制到本地，这证明旧NAS仍能提供约250 MB/秒的速度。

当网络突然变得更快时，Get-SmbMultichannelConnection显示所有四个Synology以太网接口都在参与。当/J看起来很慢，仅仅移除这个行为就能恢复我预期的吞吐量。

最终的表现并非因为从论坛中找到一个秘密的“快速机器人复制”命令。而是因为我考虑了这次迁移中真正想要哪些功能，并剔除了一些在其他情况下有用但对我来说成本较高的功能。

这大概是我下次做这件事时最想记住的部分。/Z,/J， 和/MT这些都不是性能滑块上的等级。它们改变了可重启性、缓冲和并发性。替代数据流即使资源管理器通常隐藏它们，它们仍然是真实数据。

SMB多通道可以让拥有多个千兆接口的老旧NAS比单一以太网端口所能想象的能力强得多。

Robocopy 最终是我尝试过最快的。和所有建议一样，这对我很有效。理想情况下，你会在评论区获得更多价值，因为黑客新闻的工作人员和Windows专家会带来更好的工具和策略。

记住，网络饱和的方法不止一种，我这次完全饱和了，所以我对迁移的结果很满意。

© 2025年 斯科特·汉塞尔曼。版权所有。