Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!shenkin From: shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) Newsgroups: comp.sys.sgi Subject: Re: Questions bru-ing in my mind Message-ID: <1990Dec24.155048.29640@cunixf.cc.columbia.edu> Date: 24 Dec 90 15:50:48 GMT References: <1990Dec18.211216.24299@cunixf.cc.columbia.edu> <1990Dec21.174239.11753@odin.corp.sgi.com> Organization: Columbia University Lines: 87 > = olson@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@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@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***