Sorry, I haven't contributed much to the list for a while. One of my offsite VPN client machines was moved to a slower internet link. Meanwhile, in October it went through a major automated upgrade. As a result, the nightly rsync job took longer than 24 hours. The next night's backup started before the first completed, which attempted to move all those files again, and slowed the link down further. Cascading failures. I was incredibly busy, so I turned off dirvish to that machine rather than fix the problem.
Bad mistake. That offsite machine lost a RAM, which caused it to do a lot of extra activity, and heat up and toast the disk. A week ago, it lost the disk - with no recent backups. Bad result. Well, the machine is repaired now, and will work temporarily until I replace it (currently a Shuttle ST62K mini-ITX, not so good) with something lower power and more reliable (probably a Via C7 or Intel Atom mini-ITX ). We can talk about low power computers off the list ( My new firewall will be a PC Engines ALIX, using an AMD Geode with built-in encryption engine for OpenVPN, all for 4 watts!). But I digress ... In any case, I fixed the dirvish pre-client script so this won't happen again. I hope. Whenever that client is running rsync, it will be slow, so I want to skip that night's dirvish run. I added this to the end of the pre-client bash script: --------------------------------------------------------------- ... if ps -C rsync > /dev/null then echo "rsync is already running" exit 1 else exit 0 fi --------------------------------------------------------------- The ps command returns 0 if the client is already running rsync, which causes the first if clause to execute; the pre-client script exits with an error. Dirvish notices this, and skips the rsync command and postclient script, and moves on to the next client. Otherwise, the ps returns a 1 (no rsync found) and the pre-client script exits with a 0 - no error. I will move the repaired client machine back to its home, and hope that this prevents the cascading dirvish error. If some of the backups take more than 24 hours, well, that is better than no backups at all. Keith -- Keith Lofstrom [EMAIL PROTECTED] Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs _______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
