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, 2016 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. Oct 1, 2016 at 10:47

1 Answer 1

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 Oct 1, 2016 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, 2016 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. Oct 2, 2016 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, 2016 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. Oct 2, 2016 at 19:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .