Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I'm aware of the comments saying rsync or rclone, and I absolutely also use those, but for initial migrations I often find myself simply using tar instead.

    Something like :

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

    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.

  • "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.

  • 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...

  • 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.
  • 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.

  • I agree with Scott, no need to use rsync - he should have used rclone instead! It can be easily installed in the package manager, and with 4 threads (or multiples of 4) it fully uses/saturates the 4 1GbE links.

    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)

  • Given Ubiquiti's history of abandoning entire product lines, I cannot ever imagine trusting a ubiquiti closed-source NAS product with my data. No thank you. Not when TrueNAS exists.
  • Starting with robocopy is nuts. I'd have started with rsync and just let it run overnight. The peace of mind that it'd do the right thing and not needing to research flags are more than worth any speed tradeoffs.

Explore Birbla archives