Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!charon!xochitl!mars.unm.EDU!cheeks
From: cheeks@xochitl.uucp (Mark Costlow)
Newsgroups: comp.sys.hp
Subject: Re: backup HP-UX systems over e-net
Message-ID: <193@xochitl.UUCP>
Date: 14 Mar 89 18:40:27 GMT
References: <1539@zen.UUCP> <263@verdix.verdix.com> <1345@stracs.cs.strath.ac.uk>
Sender: news@xochitl.UUCP
Organization: Ed's Research Emporium
Lines: 60
Followup-To:comp.sys.hp


We've got several 300-series machines on an ethernet, intermixed with Suns.
We have 2 8-banger (model number escapes me) tape drives for backing them up.
We are currently using dump(1M) to back up the HPs.  I do this with shell script
which run on the host machines which have the tape drives connected to them.
Essentially they just do:  "remsh RemoteMachine dump 4uf - /".  This dumps
the device to standard output, and the output of the remsh (which is the
dump itself) gets piped to tcio and out to the tape drive.  It would be
trivial to make this work from a Sun, and with Exabytes on the way, we may
just do that.  

Caveats:   restore(1M) DOES NOT KNOW ABOUT SYMBOLIC LINKS!  This is, frankly,
           a Real Pisser (tm).  It also cannot restore the net/special files
           which are used for rfa, but with nfs around that doesn't bother
           us.

           Restores have to be done in a rather strange manner ... the command
           looks something like:  "tcio -i /dev/rct8 | restore -if -",  which
           does an interactive restore from standard input.  Suprisingly enough,
           this actually works, but you obviously can't use BSD restore's 
           "which tape do you want?" feature so you have to read through ALL 
           the tapes of the dump to do it.  Full restoration of a partition
           works just as you'd expect it to and rather quickly too.

           I was a bit misleading when I said you could do this on Suns easily.
           You can do it, but due to the nature of dumping this thing through
           the network as standard output, you would need a device large enough
           to hold any given dump in order to do it.  HP's 8-banger tape-drive
           works for this, but you would run into problems with smaller things
           since dump sees standard out as a huge infinite file, as opposed to
           several discrete files (tapes).  Again, with Exabytes, this would
           not pose a problem.

FLAME ON

     I hope someone at HP is reading this ... PLEASE fix dump to handle
     all HP-UX file types.  Like I said, we don't use RFA so the net/specials
     don't bother me, but I would imagine that it does bother somebody.  And
     symbolic links are a must in a network environment.
 
     While I was able to solve our problem with dump to standard out, it's
     still an ugly hack.  Not everyone's got big disk-partition-sized archive
     devices.  Rdump is REALLY what is needed here.

     Fix find(1)!!!!!  It doesn't support the -prune option like BSD find,
     so if you try to use the find | cpio scripts which HP seems to expect
     us to use, find digs down through ALL MOUNTED NFS FILE SYSTEMS!  This
     makes dumps of that ilk take SEVERAL HOURS!  Again, if you use RFA, find
     doesn't like the net/special files either so your find commands end up
     looking like:  find /net/machine/usr/../. <find_options>.  This too is
     an ugly hack.

FLAME OFF

     I apologize if these things have been fixed in the 6.5 release which I
     haven't received yet.

Mark Costlow
System Bozo @ Large
Mail to:  ... sun!texsun!xochitl!cheeks