On Wed, Nov 08, 2000 at 09:48:13AM -0800, Tyler Hardison wrote:
> Hi everyone, I have been using rsync now for about 2 months on my companies'
> two job servers with great success. Twice when our main jobserver has gone
> down, our second "mirrored" server has picked up the ball and ran with it.
>
> However something happened last night that was very (funny to me)
> interesting. The #2 Controller on our Andataco raid cabinet died, so instead
> of calling me or my other sysadmin partner our GM decided to reboot server 1
> on his own. What ended up happening was several raid volumes did not mount
> because of a controller fault, otherwise the server came up fine including
> rsync (not rsync's fault at all). As most of you can already guess, server 2
> came calling and got empty volumes, esentially wiping server 2 out. :)
I got something similar between my 2 rpmfind mirror and I didn't found
funny at all to have to resync 120Gigs through a transatlantic IP line.
> Now my question is, does anyone have a suggestion of a test that I can run
> prior to rsync (which is run through a crontab) that I can use to stop
> rsync? The server actually wasn't rebooted for about two hours so at one
> point it was "down". Basically we sync the servers once an hour because we
> do high volume graphics editing on very critical time schedules.
Well my approach was "it's impossible to test that the source is proper",
and I sent a patch for limiting the max number of deleted files in a run.
It seems it was included in some way since rsync --help now shows:
--max-delete=NUM don't delete more than NUM files
it's not perfect but a reasonable guarantee against disasters,
Daniel
--
[EMAIL PROTECTED] | W3C, INRIA Rhone-Alpes | libxml Gnome XML toolkit
Tel : +33 476 615 257 | 655, avenue de l'Europe | http://xmlsoft.org/
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Rpmfind search site
http://www.w3.org/People/all#veillard%40w3.org | http://rpmfind.net/
