Xref: utzoo comp.unix.xenix.sco:2088 comp.unix.sysv386:6543
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.unix.xenix.sco,comp.unix.sysv386
Subject: Re: Best way to backup SCO Xenix/UNIX
Keywords: backup unix xenix sco
Message-ID: <3599@sixhub.UUCP>
Date: 2 Apr 91 04:05:58 GMT
References: <aris.670179095@tabbs>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Followup-To: comp.unix.xenix.sco
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 63

In article <aris.670179095@tabbs> aris@tabbs.UUCP (Aris Stathakis) writes:

| I'd like to know the best way to do a backup so that I can recover from
| a FULL crash i.e. having to re-install on a different machine from 
| a tape backup.  I'm sure there are lots of ways to do it, like using
| the standard backup proggram SCO give you, but find it too inflexible.

  Since you say Xenix and I've been running a bunch of these for years,
I would first say don't use tar, it skips empty directories, and they
may be needed to make things work. A new version might have cured that,
but there are other reasons.

  First, of course, you use mkdev fd to create a bootable floppy with
your current kernel and devices. When you make a new kernel for any
reason, make a new disk (don't rewrite the old one).

  For each partition take a level zero dump using the error correcting
tape device. I suggest making two and verifying them if you're paranoid.
I am, and I store one copy off site. Then take regular level one dumps
to pick up the changes. Dump saves the data a lot faster than tar, and
restores slower. Since these are disaster backups you won't restore
much, and if you do you will want reliability rather than speed.

  When/if the level one dumps get large, switch to level two. At that
point I take another level zero, and save one of my original level zero
dumps. This gives you a good full restore capability, and since it's
Xenix you have the X option to allow slow but reliable restore of
selected files.

  As an alternative for the incrementals, create a file via touch after
the level zero, and then use find and cpio to save the modified files.
The only advantage is that if you have to restore individual file often
this is a more convenient and faster way to do it. You can also use the
-mtime and/or -ctime options on find to select files. This allows taking
the level zero dumps of each individual partition, then taking one
incremental for all filesystems (if it will fit on a single tape) to
save time.

  If you use cpio use the -depth option, as it will insure correct time
modified on directories when restoring. Just in case you need it.

Summary:
  - always level zero dump
  - then level one dump or cpio
  - dump saves faster, restores slower, needs one tape/filesys
  - cpio is convenient, save all files on one tape

Example:
  from floppy boot, single user mode:
	dump 0ufk /dev/erct0 55000 /dev/hd0root
	dump 0ufk /dev/erct0 55000 /dev/ru

  incremental, single user mode highly preferred!
	(five days after level zero)
	find / \( -mtime -5 -o -ctime -5 \) -depth -print |
	cpio -oBc > /dev/erct0

Hope this isn't a lot more detail than you wanted!
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me