Join the discussion

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

  • Hacker News
  • Has anyone found a solution to lack of encryption in unas?
  • It has encryption.
  • 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.

  • He should've given bvckup2 a try.

    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.

  • Does anyone know if the UNAS range uses ZFS as well or does it use BTRFS or something else?

    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.

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

  • >simply using tar instead

    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.

  • For large transfers on a network I control I would use bare netcat, much faster than going over ssh and without having to figure out rsync server (probably easy, but I don't need another distraction.

      nc -l 8888 | tar -C /dir -xzf -
      tar -C /dir -czf - | nc server 8888
    
    rsync however, is totally worth it if there is any chance the transfer gets interrupted.
  • "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 consider it much better because rsync can detect bit errors and robocopy can't.
  • 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)

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

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

  • Fairly reasonable explanation is album cover art.
  • Yes, I certainly wouldn't have just skipped past ADS not working. Since samba and zfs support it, this is weird that Ubiquiti wouldn't. If this isn't just a config problem, I would call it cause to return the device.
  • 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.
  • I tried that once but the cifs kernel mod was so old it didnt support modern auth methods.
  • I didn't read the whole thing, but couldn't you just rsync over ssh from either end?

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

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

  • I believe that Ubiquiti advertises that they use zfs.
  • I tried that before and ran into issues due to the fact that synology's btrfs implementation has quite a few patches. I forgot exactly what issues I had, just ymmv.

    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.

  • 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.
  • Thankfully it's not dissimilar to Synology internally: btrfs+mdadm on the smaller ones, ZFS on the big ones.

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

  • Yes, TrueNAS works great sans a couple of quirks with external storage boxen. I'm mostly a happy camper.

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

  • > Given Ubiquiti's history of abandoning entire product lines

    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.

  • Basing your major infrastructure choices on Ubiquiti feels a kickstarter purchase every time. Huge claims, borderline religious following community, an intentional and almost proud absence of technical support, and a coin toss if the product line will still exist in 24 months.

    And when they work as advertised they are fantastic.

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