Questions bru-ing

[Dave Olson]

In <14372 at mcdphx.phx.mcd.mot.com> fnf at riscokid.UUCP (Fred Fish) writes:

| In article <1990Dec22.204946.28873 at odin.corp.sgi.com> olson at anchor.esd.sgi.com (Dave Olson) writes:
| >I'm not that it matters too much.  Since the cron script can only use the
| >one tape cartridge, the best you can do is to backup one tapes worth.
| >bru (or tar, or cpio) will then ask for the next tape.  Since there
| >is no controlling tty, the prompt will fail and the backup aborts.
| >You still have the first tapes worth of backup.
| 
| You can use the brutalk program to communicate with background versions
| of bru that have no controlling terminal.  This is a short program
| which EST provides in source form to all customers (not sure if SGI
| passes it on).  Bru is told to direct all queries, and receive replies,
| from a pair of fifos.  Brutalk hangs out at the other end and communicates
| with the user when required.

We don't ship it because we don't have it.  Perhaps it was added after
the version we licensed (no doubt with the hooks to make it work).  We
have made so many changes and 'enhancements' to bru that re-integrating
with the current version from EST would be a significant amount of
work.  I don't think that is likely to be done in the near future;
there are better programs to spend time and energy on.

bru is also very wasteful of tape, so it is not used by all that many
people (at least very few of the people at SGI, and judging by relative
volume of questions/problems related to tape and backup programs, by
our customers either).  It also tends to take longer to complete
backups, sometimes MUCH longer, then tar, cpio, or dump/restore

It is used by our system manager tool for backups and restores, so
it will definitely continue to be supported and bug-fixes made, but
no plans exist to update to newer versions (I hadn't even heard of
newer versions until your posting).  The integration of bru with the
system manager tool makes integrating new features from EST even more
difficult, of course.

| >If you have multiple
| >drives it would be useful to have a way to specify to bru that it
| >should switch to a subsequent drive without reading from /dev/tty,
| 
| This is called device chaining.  You simply use multiple -f options.
| I.E.
| 
| 	bru -f /dev/rmt/tp0 -f /dev/rmt/tp1 -f /dev/rmt/tp2
| 
| and bru automatically switches to the next drive when required.

Yes, this would be a nice feature, but unfortunately, it doesn't work
(at least in the version that SGI has).  The final -f option is the
only one that is used.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.