I'd appreciate a bit of help with devising a backup stratergy, or at
least checking if mine is okay. So if you have a few mins ....

Every now and again (perhaps not as often as I should do), I boot my
Sun from a CD, then back up all the file systems to tape, so
everything is unmounted (including /).

I'm looking for a sensible method to back up a home computer (Ultra
80), without too much manual intervention. The machine has quite a lot
of disk space (~200 Gb), but most of it is very old stuff and really
could be just left on tape and deleted from disks, but I tend not to
bother.

Only one file system has any data that I could not (with a bit of a
struggle) restore by other means. Hence I want to back that up
reasonably regularly, with other file systems less so.

Bear in mind

1) It's a home computer, where the loss of a few days work would be
annoying, but not catastrophic.
2) I don't have an indefinite supply of money and hence tapes.
3) In the unlikely event of a disk failure, I don't mind spending a
day rebuilding the system.
4) I don't have a fireproof safe, so move tapes off site.
5) The partition is 36 Gb, but only about 28 Gb is used. The tape
drive is a 20/40 Gb DDS-4 unit. This might mean I run out of space
with incremental backups. In that case I might consider putting
incremental backups on a 12/24 Gb DDS-3 tape drive I have in another
system.
6) The tape drive, unlike the U80, is not on a UPS. I've not
ascertained what happens if the power fails at some point - does the
tape rewind? I need to check this.

I'd appreciate comments on the following crontab file.

# Perform a backup every 3 days - an acceptable compromise between
security
# and tape usage on a home computer. I know it will be difficult to
get data
# back towards the end of the month, but tapes cost money!

# Rewind a tape on the 1st of the month, then do a level 0 dump, but
not
# rewinding after that dump.

00 04 1 * * /bin/mt -f /dev/rmt/0 rewind ; /usr/sbin/ufsdump 0fu
/dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 1 dump 3 days later on the 4th of the month.
00 04 4 * * /usr/sbin/ufsdump 1fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 2 dump 3 days later on the 7th of the month.
00 04 7 * * /usr/sbin/ufsdump 2fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 3 dump 3 days later on the 10th of the month.
00 04 10 * * /usr/sbin/ufsdump 3fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 4 dump 3 days later on the 13th of the month.
00 04 13 * * /usr/sbin/ufsdump 4fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 5 dump 3 days later on the 16th of the month.
00 04 16 * * /usr/sbin/ufsdump 5fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 6 dump 3 days later on the 19th of the month.
00 04 19 * * /usr/sbin/ufsdump 6fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 7 dump 3 days later on the 22nd of the month.
00 04 22 * * /usr/sbin/ufsdump 7fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 8 dump 3 days later on the 25th of the month.
00 04 25 * * /usr/sbin/ufsdump 8fu /dev/rmt/0n /dev/rdsk/c0t1d0s7

# Perform a level 9 dump 3 days later on the 28th of the month.
# Then eject the tape.
00 04 28 * * /usr/sbin/ufsdump 9fu /dev/rmt/0n /dev/rdsk/c0t1d0s7 ;
/bin/mt -f /dev/rmt/0 offline

--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
e-mail davek@medphys.ucl.ac.uk web:
http://www.medphys.ucl.ac.uk/~davek

On Wed, 20 Aug 2003, Dr. David Kirkby wrote:

> Every now and again (perhaps not as often as I should do), I boot my
> Sun from a CD, then back up all the file systems to tape, so
> everything is unmounted (including /).

One way of avoiding this rigmerole (sp?) is to use UFS
snapshots (these "freeze" file system updates (making a
note of them elsewhere)) while performing the backups.

> 1) It's a home computer, where the loss of a few days work would be
> annoying, but not catastrophic.
> 2) I don't have an indefinite supply of money and hence tapes.
> 3) In the unlikely event of a disk failure, I don't mind spending a
> day rebuilding the system.

Using a mirrored disk would help protect you from that
eventuality.

> 4) I don't have a fireproof safe, so move tapes off site.
> 5) The partition is 36 Gb, but only about 28 Gb is used. The tape
> drive is a 20/40 Gb DDS-4 unit. This might mean I run out of space
> with incremental backups. In that case I might consider putting
> incremental backups on a 12/24 Gb DDS-3 tape drive I have in another
> system.

If you daily (or so) incrementals, I imagine the likelyhood
of running out of space on a DDS4 tape would be small!

WHat I do is this, which is non-optimal. But long term "resting"
between contracts forces compromises to be made.

On Mon to Thu, I do an incremental backup (using a different
tape for each day). This backup saves the stuff that changed
sine the last daily backup. On Friday I backup everything that's
changed since last Friday. And on Sunday I do a full backup.

> I'd appreciate comments on the following crontab file.

[...]

I prefer to use one script that I call from cron.
Here are my entries:

59 23 * * 1-4 /opt/local/bin/backup -d
59 23 * * 5 /opt/local/bin/backup -w

I perform the full backup manually, so it's not in my crontab.
I just run "backup -f".

Below is my backup script; tailor to suit.


---------------------------------------8<---------------------------------------
#!/sbin/sh
#************************************************* ******************************
#
# Name: backup
# SCCS Id: @(#)backup 1.5 04/13/03
#
# Description: This script performs a backup of the local system. It uses
# the fssnap facility introduced in Solaris 8, and so must be
# run as root.
#
#
# Copyright (C) 2000-2003 by Rich Teer. All rights reserved.
#
#************************************************* ******************************


HOST=`uname -n`
TAPE_DEV="/dev/rmt/0cn"
FSSNAP="/usr/sbin/fssnap"
UFSDUMP=/usr/sbin/ufsdump


#
# Create a temporary snapshot of file-system, and dump it.
# backing-store should be a UFS on a different file system.
#
# If fssnap fails, a normal ufsdump is performed.
#
dumpfs() # file-system [backing-store]
{
FS=$1
BS=${2:-/var/tmp}

echo "Dumping $FS..."
if RAW_DEV=`$FSSNAP -o raw,unlink,bs="$BS" "$FS"`; then
$UFSDUMP -${LEVEL}ucfLN $TAPE_DEV $FS $FS $RAW_DEV
$FSSNAP -d "$FS" > /dev/null
else
$UFSDUMP -${LEVEL}ucf $TAPE_DEV $FS
fi
mt -f $TAPE_DEV stat
echo ""
}


case "$1" in
'-f')
echo "Full backup of $HOST started:" `date`
LEVEL=0
DONE_MSG="Full backup of $HOST finished:"
;;

'-w')
echo "Weekly backup of $HOST started:" `date`
LEVEL=5
DONE_MSG="Weekly backup of $HOST finished:"
;;

'-d')
echo "Daily backup of $HOST started:" `date`
LEVEL=9
DONE_MSG="Daily backup of $HOST finished:"
;;

*)
echo "Usage: backup -d | -f | -w"
exit 1
;;
esac
echo ""

mt -f $TAPE_DEV rew

#
# fssnap doesn't work on file systems being used
# by processes in the RT scheduling class. xntpd
# currently runs at an RT priority, so we must
# stop it while we backup the root partition.
#
/etc/rc2.d/S74xntpd stop
dumpfs / /export/home/backup
/etc/rc2.d/S74xntpd start

dumpfs /export/home /var/tmp
dumpfs /var/mail /var/tmp
dumpfs /export/install /var/tmp
dumpfs /export/share /var/tmp
dumpfs /export/src /var/tmp
dumpfs /export/pcfs /var/tmp

mt -f $TAPE_DEV rewoffl

echo $DONE_MSG `date`
---------------------------------------8<---------------------------------------

Enjoy,

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

In <3F42F7FB.2F1134D2@ntlworld.com> "Dr. David Kirkby" <drkirkby@ntlworld.com> writes:

>I'd appreciate a bit of help with devising a backup stratergy, or at
>least checking if mine is okay. So if you have a few mins ....

>Every now and again (perhaps not as often as I should do), I boot my
>Sun from a CD, then back up all the file systems to tape, so
>everything is unmounted (including /).

I think there is little harm doing backups on a 'live' system so long as
it is done when things are quiet (so the only files likely to be changing
are in some uninteresting parts of /var).

>6) The tape drive, unlike the U80, is not on a UPS. I've not
>ascertained what happens if the power fails at some point - does the
>tape rewind? I need to check this.

I would expect it to stop where it is. Maybe it rewinds automatically when
the system reboots.


># Perform a level 1 dump 3 days later on the 4th of the month.
># Perform a level 2 dump 3 days later on the 7th of the month.
># Perform a level 3 dump 3 days later on the 10th of the month.
># Perform a level 4 dump 3 days later on the 13th of the month.
># Perform a level 5 dump 3 days later on the 16th of the month.
># Perform a level 6 dump 3 days later on the 19th of the month.
># Perform a level 7 dump 3 days later on the 22nd of the month.
># Perform a level 8 dump 3 days later on the 25th of the month.
># Perform a level 9 dump 3 days later on the 28th of the month.

No, I don't think that's a good strategy for doing dumps at various
levels. Here is what I do (admittedly on a much smaller system). Note the
importance of partitioning things according to dump importance. Dumping
takes place overnight when it is known no other cron jobs are active.

Level 0 dumps are made on one tape, and incremental dumps on another.

Level dumps are made once in a blue moon (usually when the incremental
tape it full, which is about every 4 months).

Otherwise, I dump 3 times a week, as follows:

Tuesday, Thursday: (/var, /home) level 6
3 Sundays out of 4: (/, /usr, /opt, /var, /local, /home) level 4
4th Sunday: (/, /usr, /opt, /var, /local, /home) level 2

The incremental dump is not normally rewound (naturally I do 'mt eom' before
any dump). So to retrieve a given file, I have at most 4 dumps to look at,
of which the 3 incremental ones are likely near the end of the tape and
rapidly reached. Getting a file off the level0 0 is a pain, of course
(this is an ancient Exabyte which takes forever to seek the full length of
a tape). I have never had occasion to do a full restore, but occasionally
have need to "undo" a bit of unfortunate history :-) .

There is a further partition /archive which is only ever dumped at level
0, and two partitions /bigspare and /var-nodump which are never dumped.
/bigspare is a general dumping ground for ephemeral stuff (dowloaded
*.tar.gz stuff) and /var-nodump is soft links from those parts of /var
which are not of permanent value (like my news spool, lock files, and my
web browser's caches).

df -k gives:

Filesystem 1024-blocks Used Available Capacity Mounted on
/proc 0 0 0 0% /proc
/dev/dsk/c0t3d0s0 38799 20794 14126 60% /
/dev/dsk/c0t3d0s6 2255791 334766 1875910 16% /usr
fd 0 0 0 0% /dev/fd
/dev/dsk/c0t2d0s4 134191 30854 89918 26% /var
swap 232132 420 231712 1% /tmp
/dev/dsk/c0t3d0s3 1016863 164107 791745 18% /home
/dev/dsk/c0t3d0s4 1016863 328148 627704 35% /local
/dev/dsk/c0t3d0s5 2054959 400392 1592919 21% /archive
/dev/dsk/c0t3d0s7 2054959 146896 1846415 8% /bigspare
/dev/dsk/c0t2d0s6 134191 91360 29412 76% /var-nodump
/dev/dsk/c0t2d0s7 521536 228640 240743 49% /opt

Towards the end of a blue moon, the level 2 dumps are getting a bit big
(~135MB).

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5