Questions bru-ing in my mind

[Dave Olson]

In <1990Dec24.155048.29640 at cunixf.cc.columbia.edu> shenkin at cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
| > = olson at anchor.esd.sgi.com (Dave Olson)
| 
| 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?  

There is an option (-m) that says don't cross mount points.  This
makes it trivial to back up only the root partition, or only the /usr
partition, ignoring any submounts (efs, dbg, or nfs).  This would
also ignore /debug when backing up root.  Of course, this doesn't
help for /tmp, but see below.  As for backing up all of /usr except
/usr/people, how about

	find /usr/* -prune -print | egrep -v /usr/people | bru -vcm -

My main point here is that no backup program will provide all the
options that every user/system administrator wants.  It should make
it POSSIBLE to do most of them, and the ability to accept a filename
or directory list from standard input satisfies a great number of the
requests.  On the other hand, adding options for every
exclusion/selection mechanism would make bru even slower, larger, and
harder to maintain than it is today.

Since most people who do backups regularly (and don't all of us :))
set up shell scripts of some form anyway, the amount of extra typing
doesn't seem to be much of an issue.

| [[ re:  bru knowing about the length of tapes ]]
| >...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?

When you use the -s option, or a size in brutab, bru does NOT handle the EOT
from the driver correctly.  This was a design decision on the author's part
(not from SGI).

A lot of the 'design decisions' in bru seem to have been made (or justified)
on the basis that bru was supposed to be portable across a wide range of
machines and operating systems, and a number of them don't give reliable
end-of-media indications.

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

QIC 150 tapes hold VERY close to 150 Mb, hence the name.  They usually hold 1-2
Mbytes more, but the exact amount depends on a number of factors.  If  you
always use fairly new tapes, and get them from the same manufacturer, your
best bet is to use dd to size a couple of them and use the lowest value, if
you want to use -s, or the size field in brutab.

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

I'll pass this on to the documentation people.

| [[ bru -eZ ]]
| 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.

I've been convinced by you and other people's responses that -eZ
should work.  I'll change that for the next major release, probably
with a warning message at the start that it will take a long time.

Note that making such a partitioning at any time prior to the backup
always introduces the 'risk' that the size of that directory tree may
increase due to new files, growing files, core files, etc., so it may
not fit no matter what you do...
--

	Dave Olson

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