[sf-lug] SF-LUG mbox archive rsyned ~overnightly

Michael Paoli Michael.Paoli at cal.berkeley.edu
Fri Jan 10 04:52:04 PST 2020


And, as far as I know, other than what Rick backs up of
linuxmafia.com
I think I'm the only one that backs up SF-LUG's list (at
least mbox archive & roster).

Anyway, slight tweak to the mbox backup.
Most notably, since due to ISP changes, both myself (@home) and
linuxmafia.com have fair bit higher bandwidth now.

So, upped the bandwidth limit on the rsync:
$ cd ~/bin
$ rcsdiff -r1.3 sf-lug.mbox_rsync+version_control
===================================================================
RCS file: RCS/sf-lug.mbox_rsync+version_control,v
retrieving revision 1.3
diff -r1.3 sf-lug.mbox_rsync+version_control
61c61
< rsync_opts='--quiet --checksum --times --sparse --partial  
--ignore-times --compress-level=9 --bwlimit=5'
---
> rsync_opts='--quiet --checksum --times --sparse --partial  
> --ignore-times --compress-level=9 --bwlimit=312'
$ rlog sf-lug.mbox_rsync+version_control 2>&1 | sed -ne '/^revision 1\.3$/q;p'
RCS file: RCS/sf-lug.mbox_rsync+version_control,v
Working file: sf-lug.mbox_rsync+version_control
head: 1.4
branch:
locks: strict
access list:
symbolic names:
keyword substitution: b
total revisions: 4;     selected revisions: 4
description:
sf-lug.mbox_rsync+version_control
----------------------------
revision 1.4
date: 2020/01/10 11:55:13;  author: sflug;  state: Exp;  lines: +1 -1
increased --bwlimit= from 5 (KiB/s) to 312 - as both client and server  
have significantly more bandwidth now (due to ISP changes); and that  
312 should still be <~=1/2 least nominal available bandwidth (so  
should generally not come near to saturating any network bandwidth  
involved)
----------------------------
$

Oh, also, I left --compress-level=9 ... did 'bit 'o testing, that
seemed (and actually was) fastest in net (and when done without
bandwidth limit), though the differences between --compress-level=5
through --compress-level=9 were about down in the noise levels (and
didn't test enough to definitively tease 'em apart - if that would
even be doable).  When I did tests, I also mostly randomized the
ordering, so as to mostly (and especially after first) offset any
speed advantages from caching, and also mostly randomize any other
"noise" elements.

See also:
http://linuxmafia.com/pipermail/sf-lug/2019q1/013876.html
etc.




More information about the sf-lug mailing list