Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mcsun!cernvax!achille
From: achille@cernvax.UUCP (achille petrilli)
Newsgroups: comp.sys.apollo
Subject: Re: Omniback
Message-ID: <1913@cernvax.UUCP>
Date: 25 May 90 18:54:38 GMT
References: <9005251516.AA11219@umix.cc.umich.edu>
Organization: CERN, European Laboratory for Particle Physics
Lines: 69

Here I am, ready to throw in my 2 cents worth ...

In article <9005251516.AA11219@umix.cc.umich.edu> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes:
>Bryan --
>
>> First of all it takes FFFOOOOORRREEEVVVEEERRR to restore something from an 8mm
>> tape.  This is apparently due to the fact that Omniback writes the whole backup
>> (in our case, 12 nodes) to one file on the tape.
>True.  That is why backups are so much faster.  You can multiplex data-writing
>to be from up to 5 nodes simultaneously
In my experience, I do not see a big advantage in the accrued speed. The tests I
did showed not a very big improvement with respect to 'wbak | dd', yes it goes faster,
but:
	1) a 2 GB Exabyte takes just over 2 hours to fill up at full blast,
	2) I got 100KB/sec almost always from wbak, say 1/3 the full speed of
		an 8mm, so it takes 7 hours to fill a cassette,
	3) a night consists at least of 8 hours then
I don't see a difference between wbak/omniback.

>>  In order to restore even one file Omniback must search through the whole 
>> backup.
>Well, it only needs to search until it either finds it, or finds the block
>in the tape-file that specifies end-of-volume for the disk that had the info
>you're restoring.
As it is advised to run similarly sized disks together with Omniback, probably
all disks backups will end more or less at the same time, i.e. at the end of
the tape, I guess.

>> 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