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.
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.
Cyber@feddit.uk 3 weeks ago
One thing I forgot to mention:
rsynchas 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)