We're currently forced to limit the backup bandwidth to a nfs disk outside our network (thru VPN) because it fills up the modem cache and we are forced to reboot it to regain connectivity.

0 22 * * *   flock rsync_wan_lock -c "rsync --rsync-path=\"nice -n5 ionice -c2 -n3 rsync\" --bwlimit 2000 -avrPq --delete-after /var/data/ /mnt/somedrive"

But that is not sufficient. Even thought 2000 KiB it ought be 50% of transfer speed (we have 30Mbps), it still fills the buffer.

So, I've read that rsync bursts and then goes silent to honour the bwlimit and that metadata does still not honour the bwlimit. So I'm trying trickle now.

The problem is that every doc I could find uses trickle on ssh connections thru the -e option. I don't think -e will work if I'm not copying through ssh, but they give the reason that putting the trickle in the --rsync-path won't work due to the forking rsync does.

0 22 * * *   flock rsync_wan_lock -c "rsync --rsync-path=\"nice -n5 ionice -c2 -n3 trickle -s -u 1000 -d 10000 rsync\" -avrPq --delete-after /var/data/ /mnt/somedrive"

Any ideas/comments? And what's going on with this modem, since when it's so easy to overflow a modem? The previous firewall was capped at 10000 and didn't run into cache problems.


As far as your user-level rsync is concerned, there is no network between the source directory /var/data and the destination /mnt/somedrive (the network transfer to the NFS server happens behind the scenes). Therefore trickle cannot work in this use case. On the other hand, the --bwlimit qualifier does work on local transfers.

The ionice option should help, but as the --rsync-path option is ignored on local transfers there's no point trying to apply it there.

See how this works for you

nice -n5 ionice -c2 -n3 rsync --bwlimit 2000K -avP --delete-after /var/data/ /mnt/somedrive

Note that your --bwlimit 2000K is actually 20Mb/s, which is considerably more than 50% of your maximum bandwidth.

  • "Rsync-path does not work on local transfers". That can't be true. At the beginning I had it too strict and it failed to finish the backup overnight and the command does end up being what you suggested if I check it with htop. Are you certain of this? – quimnuss Nov 21 '17 at 16:04
  • @quimnuss yes. Try setting it to (say) /bin/cat or even /tmp/doesnotexist and see what happens with a destination first of /tmp/localtarget, and then as localhost:/tmp/localtarget – roaima Nov 21 '17 at 16:09
  • The question wrote --bwlimit 2000 which is 2Mbps. I wonder if the cable modem has a low upload of 1Mbps, 30Mbps sounds like a download speed. Also I wonder if the VPN has MTU problems, "cable modem cache" sounds fishy. – axus Nov 21 '17 at 16:20
  • @quimnuss speed - 2000K = 2MB = 20Mb. I usually work on powers of ten with 10 bits/byte to allow for framing overheads. The default unit for --bwlimit is KiB/s. – roaima Nov 21 '17 at 16:29
  • 1
    Now it's looking good. I'll see how's it going thru next week and accept the answer. – quimnuss Nov 24 '17 at 23:34

You can try wondershaper, from a package of the same name, which is a simple script to set global in and out bandwidth limits using the kernel's traffic shaping tc command.

  • I'd rather just limit the backup traffic. But good to know. – quimnuss Nov 21 '17 at 15:27
  • @quimnuss You can configure traffic shaping accordingly. – BillThor Nov 21 '17 at 21:59
  • How? I didn't see any reference to shape per program not per interface – quimnuss Nov 22 '17 at 16:42
  • wondershaper doesn't distinguish between LAN and WAN traffic, nor can it be program-based, so it's useless in this situation, unfortunately. – quimnuss Nov 24 '17 at 8:48

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.