Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!mcdphx!mcdchg!ddsw1!nvk
From: nvk@ddsw1.MCS.COM (Norman Kohn)
Newsgroups: comp.unix.i386
Subject: Re: Backup utilities for ix-386
Summary: strm...
Keywords: backup ix-386
Message-ID: <1989Oct19.031746.25893@ddsw1.MCS.COM>
Date: 19 Oct 89 03:17:46 GMT
References: <185@softest.UUCP> <[253554b6:333.1]comp.unix.i386;1@vpnet.UUCP> <11954@watcgl.waterloo.edu> <107@gizzmo.UUCP>
Reply-To: nvk@ddsw1.MCS.COM (Norman Kohn)
Organization: ddsw1.MCS.COM Contributor, Mundelein, IL
Lines: 29

In article <107@gizzmo.UUCP> mark@gizzmo.UUCP (mark hilliard) writes:
>I personally like to use find piped to cpio and out to tape like:
>
>find /partition -print | cpio -ocduBvm > /dev/tape&

I use a similar scheme, in a complicated shell script designed to
prevent me from messing anything up.  I'm using Bell Tech tape
with a device "/dev/tpnr" that writes but does not rewind
at the end, so that a second volume can be written.

I back up each file system individually (otherwise, the
tape may overflow and restore is difficult because the tapes
have too much data to scan efficiently).  Make file names
relative, so you can restore elsewhere in the tree (without
using chroot).  I write a short label volume in front of each
backup volume.  stream (from bell tech) or strm (if it's still
in Unix V) will immensely speed up tape speed. uport had a
bug fix requiring a specific tuning parameter for strm to work,
but I can't comment since I use bell's stream.

Finally: make sure that your script scans the tape (cpio -ivt)
for integrity lest you get a very rude surprise.

Oh, yes. DO NOT try to do your restores interactively. USE A SHELL
SCRIPT, lest you inadvertently, in your zeal to recover your precious
files, accidentally write instead of reading the tape.  (After all,
you're more used to writing it, aren't you?

-- 
Norman Kohn   		| ...ddsw1!nvk
Chicago, Il.		| days/ans svc: (312) 650-6840
			| eves: (312) 373-0564