Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!CAEN.ENGIN.UMICH.EDU!pha
From: pha@CAEN.ENGIN.UMICH.EDU (Paul H. Anderson)
Newsgroups: comp.sys.apollo
Subject: Re: Omniback
Message-ID: <4ab396e82.000f088@caen.engin.umich.edu>
Date: 30 May 90 13:20:49 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 78


	>
	 
	>> This to me makes the backup almost useless.
	>I consider the backups to be catastrophe insurance, not a "please restore me
	>.cshrc file for me"  type operation.  Therefore, to me they're not worthless.
	I think backups serve 2 purposes, one is the insurance-type operation, the other
	is archiving. I found wbak enough for insurance (at 10.2), but still, Omniback
	is no better for archiving.
	 
	>> ... we do a full backup every night.
	>Why?  I think that this may be the source of a lot of your long-restore woes.
	I also did full backups only on some machines. The reason being, it's very
	easy to reconstruct a disk if you lose it. Also if a user asks to reload the
	.cshrc file s/he just clobbered, you don't have to think, just put on the last
	tape and off you go.
	 
	>You might consider doing a full weekly (bi-weekly / monthly) with an incr
	>on every other day.  The incr backups save everything since the last FULL
	>backup (not a-la wbak (thank you Apollo!)), so at worst, you'd need to perform
	I consider omniback a step backward as wbak was able to do the two (incr with
	respect to last full and incr with respect to last backup, full or incr) type
	of incrementals, while omniback only does incr with respect to full
	(by the way, you do incr WRT full with the '-incr -nhi' flags). I don't
	think reducing the functionality is ever a good idea.
	 
	>> Is anyone out there having better, the same, or worse luck than I with using
	>> Omniback?  I am seriously considering getting the backup software from Workstation
	>> Solutions if I continue to have problems and if I can use the software with my
	>> current Apollo hardware.  Here's a good sales opportunity WS guys.
	>I am overjoyed with Omniback.  Yes, I will admit that there are shortfalls,
	>which I hope/assume will be corrected in the future.  However, Omniback has
	>made my backups faster and more painless than ever before (partly due to 8mm
	>technology, admittedly).  I also have a lot more confidence in HP/Apollo than
	>I do in a 3rd-party supplier to keep up with O/S and hardware changes that
	>HP/Apollo makes.  Perhaps this is unfounded, but I'll continue with Omniback
	>at least until I get convinced that I'm wrong.
	I agree, I wouldn't like to depend from a 3rd party for my backups, on the
	other I either do not like to depend from a layered product for my backups !
	 
	>John Thompson
	Achille Petrilli
	Management Information Systems
	CERN

The big problem that we have with Omniback is, as you've mentioned, that
it is the only Apollo software that supports the 8mm tape unit.  Our options
are severely restricted when faced with Omniback, because we already built
a backup logging system similar to that provided by Omniback, but based it
on wbak, instead.  So, if we wish to stay with our handy dandy tape software,
we are stuck with either 6250 BPI tapes, or with using 3rd party wbak support
for the 8mm units, both options are poor.

	6250 tapes are bad news, because with 75-100 gigs of data to do
full backups for, the physical storage of all those tapes becomes a big
problem.
	3rd party stuff is bad news, because I'd really rather not have
to rely on 3rd party support of such critical services such as backups.
Word processing packages, I can understand, software to run tape drives,
I don't.

The people in charge of the technical side of omniback are generally
doing the right thing.  The marketting people who are handling the large
capacity storage devices are generally screwing up.  Part of the screwup
is not their fault, since the merger made 8mm vs 4mm support more
confusing (since HP makes 4mm tape units, but not 8mm units).  Still,
the continued problems with marginal 8mm tape support are a big black
eye for HP/Apollo.

I hope they can get their act together, because things like this are
so basic and fundamental to the smooth operation of a network that even
little slip ups get translated into really big problems.  Add up enough
slips like this, and it gets awfully hard to support large networks
of these machines.

Paul Anderson
CAEN Systems Programmer
University of Michigan