Your suggestions is also very nice, you can just turn off your own PC and wait for it to finish.

I don't even think rclone can split across multiple interfaces like SMB does.

I just finished slurping all of my files off an old Synology and onto a TrueNAS server. Unlike the article here, my Syno is 2x1Gb in a LAG, so I was really only getting ~1Gbps at max.

One disappointment with TrueNAS is that it doesn't support SMB-MC unless you put each interface on a separate subnet (which is a strange limitation because Samba itself doesn't seem to suffer from this, since synology handles it fine)

With SMB you just plug in 2 NICs and you automatically get ~double the bandwidth.

In other words, yes, it may be restartable, but if it takes more than twice as long, just recopy the file(s) if needed.

If the author is reading, it would be nice to clarify that the 10g network comment is irrelevant. I was under the impression at least 1 of the devices would have a 10g link, but at least 2 of the 3 didn't. It was a bit confusing, but it's also very late where I am.

I don't know if this is better, but...an alternative is rclone, which uses rsync under the hood. It can also do parallel jobs and is restartable on any failed partial copy.

When I've had to do large Synology-to-Synology moves, that's what I've used. The multiple rsyncs in parallel really helps if you've got a lot of small files.

> rsync under the hood

Is it? I think one is written in C (rsync) and the other is in Go lang (rclone)

Also, it kinda sounds like the UNAS might not be supporting ADS' for some reason? That alone could be a problem later on...

The whole reason of the post.

And the thing what linux fanbois with rsync/rclone here absolutely ignore.

https://docs.nersc.gov/services/bbcp/

My guess is the actual bottleneck would be directory traversal and metadata stuff - i.e. trying to keep the pipe full, not saturation effects.

Yeah I know on src/dest. I've done this sort of approach countless times in various technologies in the past 40 or so years, but that always puts the mechanism for checking things in onus of the human rather than having that one command that does it all right.

Anyway, not a slight on rsync in the slightest - it doesn't have this probably because no-one realistically actually needs it most of the time.

If you want to get the advantage of SMB multi stream copies (in rsync*), look for LACP or other options. Not sure if Synology does that though.

I'm honestly surprised that SMB was faster here. I've never had luck getting it to perform well, so this is a bit of a shock.

for example, Immich is a huge upgrade to Synology photos. I didn't know how much i was missing out.

Asynchronous IO, multithreaded for smaller files, serialized when they are big, block-level delta copying on subsequent runs. Pretty much as fast as it gets on Windows.

Also a hint for anyone planning something similar: if you use Synologys SHR format (based on mdraid+btrfs) and your new destination supports or uses BTRFS too, you can just btrfs send your whole pool to the new NAS!

(Since its a single process it wont saturate any LAG though)

The fact that synology's btrfs is incompatible with a normal linux distribution and that the official instructions from synology for reading it is to use an older kernel together with ubuntu 16.04 lts convinced me to switch away from synology.

Something like :

    (cd /src/dir && tar cf -) | ssh user@host "(cd /dst/dir && tar xvf -)" 

It won't saturate 4 multichannel links, you'll most likely need rclone or rsync for that (or robocopy it appears), but it's much faster than rsync on initial copies.

Then for good measure, once the tar copy finishes, I run a single rsync verification between the two targets.

That being said, my latest storage migration was performed using either ChronoSync or Carbon Copy Cloner from my Mac mini server. They won't do anything rsync cannot already do, except present data and copy history in a graphical environment.

  nc -l 8888 | tar -C /dir -xzf -
  tar -C /dir -czf - | nc server 8888

Be aware that tar doesn't preserve creation/birth times and keeping that original metadata is important to some people if the target file system can record it. Robocopy preserves/transfers creation times by default and recent rsync versions (3.2.3 2020-08-06) can do it with the extra option --crtimes.

And when they work as advertised they are fantastic.

Huh, this is news to me but seems to check out from my Googling. I've really been enjoying the Ubiquiti ecosystem and was considering a UNAS to replace my Seagate NAS.

In the past 5 to 7 years they have abandoned a number of entire product lines and left the people running it hanging, with no way to purchase replacement parts, or keep a system running.

I believe I'll be more happierer as I integrate it to my life more and more.

Shouldn't be hard to migrate if it got discontinued.

I only know their higher end enterprise range specifically said ZFS but all the others doesn't seems to mention it. And I really wish there is a simple 4 bay ZFS NAS.

If they would allow me to send them email saying: "I hereby promise I wont record my neighbours having little tete-a-tete."

Sure I understand liability. But requiring consumer to buy another product to fully utilize they other product? Sorry but no. They have really cool hardware and nice UI but policy like that... no.