Comment on

ryper@lemmy.ca ⁨3⁩ ⁨weeks⁩ ago

• Suburbanl3g3nd@lemmings.world ⁨3⁩ ⁨weeks⁩ ago

  I couldn’t tell you but I used it on my Rpi4 to sync 4tb of stuff from my Plex drive to a backup and set a script up to have it check/mirror daily. Took a day and a half to copy and now it syncs in minutes tops when there’s new data

  source
• GreenKnight23@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

  yes, it’s the right way to go.

  rsync over ssh is the best, and works as long as rsync is installed on both systems.

  source

  • qjkxbmwvz@startrek.website ⁨3⁩ ⁨weeks⁩ ago

    On low end CPUs you can max out the CPU before maxing out network—if you want to get fancy, you can use rsync over an unencrypted remote shell like rsh, but I would only do this if the computers were directly connected to each other by one Ethernet cable.

    source
• Cyber@feddit.uk ⁨3⁩ ⁨weeks⁩ ago

  It depends

  rsync is fine, but to clarify a little further…

  If you think you’ll stop the transfer and want it to resume (and some data might have changed), then yep, rsync is best.

  But, if you’re just doing a 1-off bulk transfer in a single run, then you could use other tools like xcopy / scp or - if you’ve mounted the remote NAS at a local mount point - just plain old cp

  The reason for that is that rsync has to work out what’s at the other end for each file, so it’s doing some back & forwards communications each time which as someone else pointed out can load the CPU and reduce throughput.

  (From memory, I think Raspberry Pi don’t handle large transfers over scp well… I seem to recall a buffer gets saturated and the throughput drops off after a minute or so)

  Also, on a local network, there’s probably no point in using encryption or compression options - esp. for photos / videos / music… you’re just loading the CPU again to work out that it can’t compress any further.

  source

  • ryper@lemmy.ca ⁨3⁩ ⁨weeks⁩ ago

    It’s just a one-off transfer, I’m not planning to stop the transfer, and it’s my media library, so nothing should change, but I figured something resumable is a good idea for a transfer that’s going to take 12+ hours, in case there’s an unplanned stop.

    source

    • Cyber@feddit.uk ⁨3⁩ ⁨weeks⁩ ago

      One thing I forgot to mention: rsync has an option to preserve file timestamps, so if that’s important for your files, then thst might also be useful… without checking, the other commands probably have that feature, but I don’t recall at the moment.

      rsync -Prvt <source> <destination> might be something to try, leave for a minute, stop and retry … that’ll prove it’s all working.

      Oh… and make sure you get the source and destination paths correct with a trailing / (or not), otherwise you’ll get all your files copied to an extra subfolder (or not)

      source