From: ericm@microunity.com (Eric Murray)
Subject: Re: BudTool
Organization: MicroUnity Systems Engineering Inc.
Date: Fri, 21 Aug 1992 00:53:38 GMT

In article <1992Aug20.154953.8495@msuinfo.cl.msu.edu> jpd@discovery.msu.edu writes:
>It's one of many good one's.  We chose it here becouse it best
>fit our needs.  My only complaint is the the secure retrivial is
>GUI only.  This means my PC user's must use a sun to get back a
>lost file.  Rumor has it that it's in the works.... But, phone/tech
>support is excellent.

Well, more like "acceptable" in my opinion...

I've been setting up budtool to back up an Auspex.  Here's the
problems I've discovered:

1. budtool is GUI-based, and can NOT be run from the command line.
Worse, manual (i.e. non-scheduled) backups will silently die if the GUI
is killed while the backup is running.  This makes it hard to dial up
from home and run a manual backup when you've screwed up the schedules
or the wrong tape was in the stacker (more about that later).  Delta
Micro seemed uninterested in supplying a command-line program to start
up a manual backup from a dumb terminal when I asked them, but maybe I
asked the wrong person.

2. budtool doesn't work right with the Auspex's 'rotating mirror'
system.  (the 'rotating mirror' allows you to mirror an in-service
partition while it's running, then disengage the mirror and dump a
quiescent disk.  It's way cool).  What happens is that dump thinks
you're dumping the rotating mirror disk, not the disk that you're
really dumping.  It'll dump it allright, but will get the dumpdates
entry and budtool's file history database wrong.  We managed to write a
hack go get around this, but the Delta salesdroid swore that it 'works
fine' with the Auspex rotating mirror.  (BTW, mail me for info if you
have an auspex and Budtool and want to know how we're doing this).

3. the secure-retreival tool will NOT allow you to display it on an X
server that isn't on the machine that the client is running on (it's
doing an XaddHost() call).  This is a killer for me, since we have a
lot of differnent machines and X servers that can't run the secure
retreival binaries.  It took me a week to get the support people to
understand the problem, but they've promised to send me a fix
tomorrow.

4. I'm using a 'dumb' exabyte 10 stacker.  This is the one that doesn't
have the capability for randon access of tapes; it just grabs them in
order (and can be set up to loop through them all and then start
over).  Unfortunately, Budtool when it's dealing with a stacker,
assumes that you set the stacker up before each backup so that the tape
in the drive is the first tape to be used in the backup.  A reasonable
assumption for a non-looping stacker, but for a looping one that may be
left at any random tape by a user's retreive operation, it's a bad
deal.  Again, a fix is promised and I've written a work-around
to get me by until then.



Overall, I think that it's fairly well designed.  There's a few
rough edges, some of which are being addressed.  The ability to
use 'standard' UNIX backup formats like dump and tar, and to
define your own, is a major bonus.  I still think it's better
than any of the others.  I just wish I had the time to write my
own backup program, so it'd work EXACTLY like I want...



--
  Eric Murray                                             ericm@microunity.com
    This package contains one (1) Usenet news posting.  Do not eat.