The moment the /Z option showed up I figured there'd be an issue. I have to copy multi-TB files often using Robocopy. We originally used /Z because "Well, if it gets interrupted, I'd obviously want to restart from where I left off..." I accidentally left the switch off one day and noted it completed in less than half the normal time (of using the /Z flag).
In other words, yes, it may be restartable, but if it takes more than twice as long, just recopy the file(s) if needed.
The Synology web UI lets you mount a remote SMB share and copy files directly in their file manager without making the round-trip via your PC, I imagine this would have been the fastest method without getting bogged down in command-line tools.
"Ideally you'll find more value in the comments as Hacker News folks and Windows experts will drop in with better tools and strategies."
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.
Moving Synology-to-Synology, I was surprised at how easily I could just move the original HDDs (in their original order) from old enclosure to new enclosure, and it just worked.
The issue with rclone compared to rsync for existing files is it will copy the whole thing again, where rsync uses something called delta transfer and only transfer the change. But if you are doing one time cloud to cloud transfer then yeah rclone is the gold standard.
> rsync under the hood
Is it? I think one is written in C (rsync) and the other is in Go lang (rclone)
I love this kind of step-by-step solving post, but it bothers me that the author didn't track down what the JPEG in the Alternate Data Stream (ADS) was for. Something put it there... Might it be a surprise when it ends up not being there later?
Also, it kinda sounds like the UNAS might not be supporting ADS' for some reason? That alone could be a problem later on...
Sometimes when we Linux for a long time, we run into decades old friends: grep, sh, bc, whatever. Not uncommon to run a command that first released 50 years ago. Rarely on Windows do we get that. As much hate as windows gets, at least they left in more than just explorer drag and drop.
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.
It really feels like rsync should have a multi-path setting that would have sped this up across multiple links (but doesn't because noone has made it yet).
rsync tends to be a bit tougher on smaller CPUs. scp is generally better for those cases if you don't mind hashing afterwards to confirm everything made it without bit flips (in theory it shouldn't happen, but I've definitely had corruption during transfers like these). I personally prefer that method because you check files that are out of page cache and at rest on the filesystem.
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.
LACP does not work well with SMB multipath and will generally prevent you from seeing the benefit. You want IP addressed adapters for each link on both sides of the conversation.
The moment the /Z option showed up I figured there'd be an issue. I have to copy multi-TB files often using Robocopy. We originally used /Z because "Well, if it gets interrupted, I'd obviously want to restart from where I left off..." I accidentally left the switch off one day and noted it completed in less than half the normal time (of using the /Z flag).
In other words, yes, it may be restartable, but if it takes more than twice as long, just recopy the file(s) if needed.
The Synology web UI lets you mount a remote SMB share and copy files directly in their file manager without making the round-trip via your PC, I imagine this would have been the fastest method without getting bogged down in command-line tools.
"Ideally you'll find more value in the comments as Hacker News folks and Windows experts will drop in with better tools and strategies."
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.
Moving Synology-to-Synology, I was surprised at how easily I could just move the original HDDs (in their original order) from old enclosure to new enclosure, and it just worked.
The issue with rclone compared to rsync for existing files is it will copy the whole thing again, where rsync uses something called delta transfer and only transfer the change. But if you are doing one time cloud to cloud transfer then yeah rclone is the gold standard.
> rsync under the hood
Is it? I think one is written in C (rsync) and the other is in Go lang (rclone)
I had the same reaction. rclone is not built on rsync. It's an independent implementation in Go, inspired by rsync.
I consider it much better because rsync can detect bit errors and robocopy can't.
I love this kind of step-by-step solving post, but it bothers me that the author didn't track down what the JPEG in the Alternate Data Stream (ADS) was for. Something put it there... Might it be a surprise when it ends up not being there later?
Also, it kinda sounds like the UNAS might not be supporting ADS' for some reason? That alone could be a problem later on...
Fairly reasonable explanation is album cover art.
Sometimes when we Linux for a long time, we run into decades old friends: grep, sh, bc, whatever. Not uncommon to run a command that first released 50 years ago. Rarely on Windows do we get that. As much hate as windows gets, at least they left in more than just explorer drag and drop.
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.
My interpretation is that the setup is 10GbE UNAS Pro 8, 4x 1GbE Synology DS 1520, 1x 2.5GbE Windows host.
It really feels like rsync should have a multi-path setting that would have sped this up across multiple links (but doesn't because noone has made it yet).
I use bbcp for that, it supports multiple streams.
https://docs.nersc.gov/services/bbcp/
Has anyone found a solution to lack of encryption in unas?
It has encryption.
rsync tends to be a bit tougher on smaller CPUs. scp is generally better for those cases if you don't mind hashing afterwards to confirm everything made it without bit flips (in theory it shouldn't happen, but I've definitely had corruption during transfers like these). I personally prefer that method because you check files that are out of page cache and at rest on the filesystem.
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.
LACP does not work well with SMB multipath and will generally prevent you from seeing the benefit. You want IP addressed adapters for each link on both sides of the conversation.
It shouldn't be shocking SMB is very fast and more secure than NFS. Hell it supports running over quic now
i recently went from synology to truenas all flash. i do not miss synology one bit. the opensource ecosystem is already there.
for example, Immich is a huge upgrade to Synology photos. I didn't know how much i was missing out.
Flash is rather expensive for storing photos and video.