2000-08-31-05:33:47 [EMAIL PROTECTED]:
> What I'd like to do is keep a longer history. In particular, I'd
> like to have "snapshots" of the system at several points in time
> (eg., last month, last week, yesderday).
>
> Currently, I do this by keeping several complete mirrors of my
> filesystem and have script files to "rotate" the backups as they
> expire.
>
> Is there a more efficient way to do this? In particular, is
> there a way to keep one mirror (eg., once a month), and then
> keep only the incremental changes to it? This is analogous to a
> differential or incremental backups.
I keep a primary backup, the mirror for e.g. recovery from drive
failure, that's a full mirror of the most recent image of the
backed-up directories; then I keep a history of previous states
of the backed-up dirs alongside; I keep that history in bzipped
tars, and my backup script does periodic housekeeping to keep the
total utilization of space in the backup area (c. 135GB) in the
neighborhood of 80-90%. The backed-up dirs are on filesystems
comprising a total of about 50GB, although they aren't all full.
This strategy is keeping about 2-3 months of history, although that
of course will depend on the activity of the filesystem. Note also
that this strategy doesn't allow full restores of a prior,
historical state of the filesystem; it's only good for single-file
recovery from history. But I only do full restores off the most
current, and only keep history for users who delete or destroy files
that they shouldn't have, and only realize it days or weeks later.
rsync's "--backup-dir" option is _sweet_ for doing this. I use the
attached script.
Usage notes on this script:
/backup is the backup area; that's hard-coded throughout the script,
but every instance of the string "/backup" refers to the backup
filesystem, so global search-n-replace would work fine for changing
it. Do _not_ make the backup area a subdirectory of something you're
already backing up, on the same filesystem; the backup script isn't
coded to defend itself against the recursion that would set up.
The list of directories to back up is coded as a paragraph of
invocations of a subroutine to backup a single filesystem; to allow
the script to automatically do both full and incrementals (a full if
no full has ever been taken before, incrementals thereafter) it
dispatches to either a fullback() subroutine or an incrback()
subroutine through a shell variable $back. The first arg is the src,
the 2nd arg is the dst (each src directory is backed up into a
separate subdirectory on the dst). The script currently contains
$back / root
$back /home home
$back /usr usr
$back /export export
I invoke it out of root's crontab every 6 hours. It's got code at
the top, associated with the output logging, to defend itself
against having multiple instances running at once. Hasn't happened
yet, in a half year of continous operation.
-Bennett
#!/bin/sh
die(){ echo `basename $0`: $*>&2; exit 1; }
test -f /backup/is-running && die "backup is already running"
exec >/backup/is-running 2>&1
trap "mv /backup/is-running /backup/log" 0
set -x
tsdir=`date +%Y/%m/%d`
tsfile=`date +%H:%M:%S`
dir=/backup/current
bck=/backup/$tsdir/$tsfile
fullback(){
mkdir -p $dir/$2
(cd $1; find . -xdev -depth|cpio -pdm $dir/$2/)
}
incrback(){
test -d $dir/$2 || die $dir/$2 does not exist
mkdir -p $bck/$2
rsync -aSbxq --delete --backup-dir=$bck/$2 $1/. $dir/$2/
}
if test -d $dir; then
back=incrback
else
back=fullback
fi
cd /backup
if df .|perl -lane 'exit($F[4]<90) if 2..2'; then
find [0-9][0-9][0-9][0-9] -type f | sort | \
while read f && df .|perl -lane 'exit($F[4]<80) if 2..2'; do
rm $f
done
find [0-9][0-9][0-9][0-9] -type d -depth|xargs rmdir 2>/dev/null
fi
$back / root
$back /home home
$back /usr usr
$back /export export
if test $back = incrback; then
cd /backup/$tsdir
umask 077
tar cf - $tsfile | bzip2 >$tsfile.bz2 && rm -rf $tsfile
fi
PGP signature
