Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy, SMB Multichannel, and Surprising Performance Traps

I’ve had a Synology NAS for a very long time, and recently I started moving its contents to a new Ubiquiti UniFi UNAS Pro 8. This seemed like it ought to be a fairly boring operation. Both devices speak SMB, I have a fast network (recently upgraded to 10 gigabit internally), and Windows has had tools for copying files reliably between machines for decades. Naturally, it turned into a whole evening of learning things I thought I already knew, which is why I started a blog lol. There was a nice bit of history here for me because back in 2007 (good lord!) I wrote a post called “XCopy considered harmful - Robocopy or XXCopy or SyncBack.” My argument at the time was basically that once you are moving enough files, Explorer stops being the move and Robocopy starts looking pretty good. I even used /Z, Robocopy’s restartable mode, because being able to resume a partially transferred file was useful on unreliable connections. Almost twenty years later, /Z turned out to be one of the most important things I needed to remove because it made everything hella slow. The migration The basic job was straightforward. I had shares on the Synology such as: \\server\music and matching shares on the UNAS: \\UNAS-Pro-8\music I initially used Explorer, mostly because it was there and because sometimes the easy thing really is the easy thing. That lasted until Explorer started producing errors on individual files: The requested operation could not be completed due to a file system limitation My first thought was filenames. NAS migrations are full of opportunities to discover that one filesystem is more permissive than another, and there were filenames with parentheses and other punctuation in them. Then this failed: \\server\music\Athlete\Tourist\05 Wires.m4p There is nothing especially exotic about 05 Wires.m4p, so I moved over to Robocopy to get a little more information.

That worked. I then copied the local file from Windows to the UNAS, and that failed with the same filesystem limitation. That isolated the problem so the Synology could read the file, Windows could store it, and something about writing this particular file to the UNAS was causing trouble. Alternate Data Streams, again NTFS files can contain named Alternate Data Streams in addition to the ordinary unnamed stream that we usually think of as the contents of a file. This is an old Windows filesystem feature, and it happens to be one I wrote about in 2007 when discussing Zone.Identifier, which Windows can use to record where a downloaded file came from. I even blogged about Alternate Data Streams in 2003!!! Windows can expose these streams with DIR /R.

Alongside the normal 4.5 MB music file was a roughly 360 KB named data stream called 01APIC_03.jpg. That also explained the strange 92% failure. Robocopy was successfully getting through the main contents of the file and then encountering the additional stream. What had looked like a failure somewhere in the middle of an ordinary .m4p file was actually occurring when Windows attempted to deal with the additional filesystem data. Robocopy has support for exactly this situation. Microsoft documents X as one of the /COPY flags, meaning “skip alternate data streams.” So: /COPY:DATX means copy the file’s data, attributes, and timestamps, but do not copy the alternate streams. /DCOPY:DATX applies the corresponding behavior to directories. I retried the same file: robocopy "\\server\music\Athlete\Tourist" "\\UNAS-Pro-8\music\Athlete\Tourist" "05 Wires.m4p" /R:0 /W:0 /COPY:DATX /DCOPY:DATX /V and it completed successfully. The important distinction here is that DATX does not remove metadata stored inside an MP3, M4A, M4P, JPEG, or other file format. It tells Robocopy not to reproduce separate filesystem streams associated with the file. In my case those extra streams were not something I needed to preserve on the new NAS. The copy worked, but it was slow Once the ADS issue was understood, I started the larger migration with a fairly conventional-looking Robocopy command: 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" It ran, but performance was all over the place. Sometimes I would see a few hundred megabits per second, then it would drop dramatically. A small file could appear to sit there for a long time. I started wondering whether I was looking at buffering, slow disks, parity calculations, SMB behavior on the UNAS, or maybe my Synology had finally reached its limits. So now it's "just try random stuff (bisect)" time. I reduced the number of threads. I tried single threaded. None of that helped. Then I removed /Z. Microsoft’s Robocopy documentation describes /Z as restartable mode, which lets an interrupted file resume rather than starting again from byte zero. What I had forgotten is that Microsoft’s current migration guidance specifically warns that /Z should be used cautiously because the extra logging required for restartability can significantly reduce copy performance.