Site Sponsors:
Zombiewatch: Pre-Backup Safety Check 
A friend of mine (all-right - it WAS me :) has been increasingly disturbed by the amount of zero-length files he as been seeing.

While having a proper backup scheme goes the very long way toward mitigating the effect of data loss, one nevertheless needs to know when bad things are happening.

The Script


With all due respect to popular culture at the moment, I have ever called my empty-headed, zero-length files "zombies." -Not only can the zeb-files creep up on us unexpectedly, but tracking down their source might well just consume most of one's brain. (for example, having zero-length .proprieties files are not necessarily evil (etc.))


Ultimately - much like their popularized namesakes, file-zombies can also do some pretty strange things... -Especially to automated backup routines! (i.e. A file goes 'zombie, and is then propagated throughout a proper backup chain. --Better it is to inspect and delete any new zombies well BEFORE allowing them to over-write their adequately-archived namesakes?)


#! /bin/bash
rm omonitor.txt
mv monitor.txt omonitor.txt
zdate=`date`
zcount=`find /d_drive -type f -size 0 | wc -l`
zreport="$zdate found $zcount zombies"
echo $zcount > monitor.txt
echo $zreport >> monitor.log
zdif=`diff -q monitor.txt omonitor.txt`
if [ -n "$zdif" ]; then
tail monitor.log > report.txt
gedit report.txt
fi
echo $zdif

The way the Zombiewatch script works is simple: In addition to keeping a log, the script will monitor the difference between the last zombie-count and the present.


Once any change is detected, you will see the last 10 entries in the log file pop up.



Using The Shotgun


To use the above script, just change that d_drive place-holder to the folder where you keep your most important files.

Note also that the script complains about missing counter-files the first two (2) times it is run. (Think of those two reports as the well-oiled "click-click" of your new Zombie-watch shotgun ...?)

Booya.

Testing


Once primed, one can test the script at any time by simply changing to the script's folder, then updating the monitor.txt file.

e.g:

echo booya > monitor.txt
./*.sh

The zombie-report file will be both generated, as well as displayed.

Easy-peazy.

Where & When


At a minimum (I use a combination of cron, as well as the backup-account's .bashrc), be sure to run the Zombiewatch script BEFORE doing a backup.

Note that I also have a shareware title I have been working on (and off... and on... and off) for years now. --Let me know if you would like it to wing its way into the public domain, and we might just charge a few more neurons around it.

Infestations


p.s. For those who discover that they have an ACTIVE zombie problem, it might help to add a historical feature:
#! /bin/bash
rm omonitor.txt
mv monitor.txt omonitor.txt
zdate=`date`
find /d_drive -type f -size 0 > "$zdate.found"
zcount=`cat "$zdate.found" | wc -l`
zreport="$zdate found $zcount zombies"
echo $zcount > monitor.txt
echo $zreport >> monitor.log
zdif=`diff -q monitor.txt omonitor.txt`
if [ -n "$zdif" ]; then
tail monitor.log > report.txt
gedit report.txt
fi
echo $zdif

Using the above, whenever new zombies are detected, all one need do is a simple `diff` on *.found files so as to track 'em down to their source. ((See `man diff` for more information.))


May THIS source be with you... always.


-Rn



[ add comment ] ( 1486 views )   |  permalink

<<First <Back | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | Next> Last>>