3

I am trying to back up the whole filesystem from one Debian development machine to a NAS on my local network. Over Samba, I am able to achieve (somehow) better than gigabit speeds at 130MBps, however over rsync, I am getting a max of 25MBps. When you have around 100GB of data to transfer, this is obviously taking some serious time!

I can only presume it's the encryption that is slowing things down and as it's local network only, I presume I don't really need encryption.

I am just creating a complete copy of what's on the development machine, so it needs to detect changes and remove them off the destination (which is why I am using rsync).

Here is my current command:

rsync -avz -e "ssh -p 903" --progress --exclude= {"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / user@IP:/volume1/Backups/NUC --delete

I think because I am using non-standard ports it's causing issues.

Is there any way to speed up this transfer at all? Ideally, I'd like to create images of the development machine so it can just be restored if needed but not sure this is possible using cron.

I have added tags like

-c arcfour

but this seems to cause problems for some reason.

Is there anything better than rsync for just creating a duplication of one system to another as a backup? Or is rsync the right method, just with lower/without encryption?

2
  • Try telling rsync to use rsh instead of ssh - no encryption so faster. Parameter is --rsh=rsh. – steve Oct 1 '16 at 9:06
  • If you want images of the machine take a look at the beta of Veeam Endpoint. Free to use (even professionally) but commercial software. – roaima Oct 1 '16 at 10:47
4

Your problem is probably the -z flag. It enables compression. It might sound like a good idea at first. At gigabit connection speed it will take more CPU time to compress than to just transfer the data. Keep in mind that most NAS setups don't have much CPU power, so this is extra expensive here.

8
  • Also consider the --partial flag to handle restarted transfers – roaima Oct 1 '16 at 10:49
  • Thank you, Martin. I have removed the -z flag but this hasn't made any difference I'm afraid. – Dan Oct 2 '16 at 19:05
  • What kind of CPU do you have? Do they have AES NI? Check with lscpu | grep aes. My Core i5-2520M has it and it can do lots of AES. Changing the cipher to something else will force the CPU to compute it “by hand” which will be slower. – Martin Ueding Oct 2 '16 at 19:13
  • I have an i3 Skylake that's about two months old in an Intel NUC. Your command doesn't return anything unfortunately! :( – Dan Oct 2 '16 at 19:28
  • What exact CPU is it? You can run lscpu and just look at “modules”. If there is no AES thing in there, your CPU has to do AES encryption “by hand”. In that case it should actually free up some performance by using an outdated cipher. – Martin Ueding Oct 2 '16 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.