Synology 迁移 UniFi：Robocopy 的性能陷阱
Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy, SMB Multichannel
我将 Synology NAS 的数据迁移到 UniFi UNAS Pro 8，本以为只是简单的 SMB 复制，却意外踩进了 Robocopy 的性能陷阱。起初，文件复制因 NTFS 的 Alternate Data Streams 而频频报错，最终通过调整 /COPY:DATX 参数解决。更令人意外的是，经典的 /Z 重启模式在稳定内网中反而拖慢了速度，而 /J 无缓冲模式在 NAS 对传场景下也表现不佳。通过深入排查，我意外发现老旧的 Synology 借助 SMB Multichannel 技术，利用四网口聚合实现了惊人的传输效率。这次经历提醒我们，命令行参数并非万能，理解底层机制比盲目堆砌选项更重要。
命令行开关描述的是一种行为，而非保证的性能提升。
HN 评论区
58- walrus01
鉴于 Ubiquiti 放弃整条产品线的历史，我根本无法想象会信任他们闭源的 NAS 产品来存放我的数据。谢谢，不必了。毕竟 TrueNAS 还在那里呢。
- internet2000
一开始就用 robocopy 简直是疯了。我肯定会先用 rsync，然后让它通宵运行。那种确信它会正确处理、无需研究各种参数的安心感，远比任何速度上的妥协更值得。
- throwaway270925
我同意 Scott 的观点，没必要用 rsync——他本该用 rclone！它可以通过包管理器轻松安装，并且配合 4 个线程（或 4 的倍数），就能完全跑满那 4 条 1GbE 链路。
另外给有类似计划的人提个醒：如果你用的是 Synology 的 SHR 格式（基于 mdraid+btrfs），而你的新目的地也支持或使用 BTRFS，那你直接可以用 btrfs send 把整个存储池迁移到新 NAS！
（不过因为是单进程，它没法跑满 LAG 带宽）
- 8fingerlouie
我知道有人提到了 rsync 或 rclone，我也绝对在用这些工具，但在做初始迁移时，我往往发现直接用 tar 就足够了。
类似这样的命令：
(cd /src/dir && tar cf -) | ssh user@host "(cd /dst/dir && tar xvf -)"
效果就不错。
它确实跑不满 4 条多通道链路，你可能确实需要 rclone 或 rsync（看来 robocopy 也行），但在初始复制阶段，它比 rsync 快得多。
然后为了保险起见，tar 复制完成后，我会在两个目标之间再跑一次 rsync 进行校验。
话说回来，我最近一次存储迁移是用 Mac mini 服务器上的 ChronoSync 或 Carbon Copy Cloner 完成的。它们能做的 rsync 都能做，唯一的区别就是能在图形界面中展示数据和复制历史。
- Neywiny
有时候，当我们用 Linux 久了，就会遇到那些几十年前的老朋友：grep、sh、bc，随便哪个都不少见。运行一个 50 年前就首次发布的命令，这再正常不过了。而在 Windows 上，这种情况很少见。尽管 Windows 招人恨，但至少他们留下的功能不止是资源管理器的拖拽操作。
如果作者能看到这条评论，最好能澄清一下关于 10G 网络的评论其实无关紧要。我原本以为至少其中一台设备有 10G 链路，但三台设备里至少有两台并没有。这有点让人困惑，不过可能也因为我这里时间太晚了。