[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