Questions bru-ing in my mind

[Peter S. Shenkin]

> = olson at anchor.esd.sgi.com (Dave Olson)

The overall question is one of backup strategy.  I think that one would
like to be able put together a strategy that backs up the entire file 
system, or a specified part of it, on close to the minimal number of tapes, 
such that no archive takes up more than a single tape.  Why this last proviso?
-- after all, one of bru's strengths is that its archives CAN span several
tapes.  The reason is that it becomes extremely laborious to restore or backup
a given file or group of files from or to a multi-volume archive.  It cannot
be done unattended.  If I know that what I need to restore is on a given tape, 
or that what I need to backup will fit on a single tape, I can stick it in,
type my command and go home.  It seems reasonable that bru should provide, if
not complete means of doing this, at least sufficient flexibility to allow
me to do it by means of additional programs such as scripts.


In article <1990Dec21.174239.11753 at odin.corp.sgi.com> you write:
[[ re: backing up a directory "except for" certain files or subdirectories ]]
>
>It is relatively rare to want to back up a whole directory tree except
>for a few files.....

I must say, I am surprised to hear this.  I would think that backing
up root except for /usr, /tmp and /debug, and backing up /usr except for
/usr/people, would be the most common operations, aside from
backing up /usr/people.  What alternative do most people use, when
doing maintenance backups?  

In retrospect, the ability to specify "backup everything in some filesystem
except something else," where the something-else might be taken from a file,
for instance, would be a frill, rather than a necessity.  One can certainly
work around this by using either a pipe or else a file containing the
file-names to be backed up.  Though then the information you have to keep
around to tell you what the hell is on the tape is much more verbose.

--------------

[[ re:  bru knowing about the length of tapes ]]

>I'm not clear on what you mean by 'recognize' here...
>...There is absolutely no way to determine tape lengths
>ahead of time, since e.g. a QIC 150 drive could have either QIC150 or
>QIC120 cartridges, in any of several lengths....

Thanks -- I understand now.  I was assuming bru used the size field in
/etc/brutab.  I noted that some of these were non-zero, but I see now
that these are not for the QIC-150 drive.  

It seems that there would be no problem in making size correspond to
the size of the recommended tape -- if the actual tape were shorter, 
then presumably the end-of-tape signal would over-ride it, no?

Now, a naive question.  If I do want to edit /etc/brutab, how do I
figure out how to set the size?  For instance, I have a DC 6150 which is
620 Ft. in length, and that also says 12,500 FTPI on it.  What is the size?

Section 7 of the IRIX System Administrator's Guide is called "Disk and
Cartridge Devices", and on the first page it tells me that one of the
topics it will discuss is "tape device sizes", but as far as I can see
there is no reference whatsoever to this subject in the chapter, and the
tps and mtio man pages are equally unenlightening.

---------------

[[ bru -eZ ]]
>
>The reason it doesn't do this is that it would actually have to read and
>compress every single file in order to determine how much space the
>compressed files would require.  This is incredibly slow....

But if I could do this, I could do something like
	bru -evZ / >& tmpfile
at the beginning of my backup day.  It would take a few hours to run,
but then I could feed tmpfile into an awk script or other simple program which
would divvy the files up into single-volume-sized groups, and then I could
bru the groups one by one.  It would seem simpler to allow than to disallow
this, so why prevent this use?

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

... and maybe change it, too!

	-P.
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb**************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY  10027
(212)854-1418  shenkin at cunixf.cc.columbia.edu(Internet)  shenkin at cunixf(Bitnet)
***"In scenic New York... where the third world is only a subway ride away."***