Re: Finding out which volumes have been backed up

[Peter Lister, Cranfield Computer Centre]

> 1.  The backup directory also has the "tapeconfig" file. 

So? Why should backup logs behave differently from fileserver, volserver, 
salvager logs?

> 2.  Butc does not check the VLDB. Moving the volume after butc has
> started a dump but prior the volume has been dumped will result in butc
> not finding the volume. This is also true with AFS 3.3. 

In personal email a few weeks ago, Dawn Johnson clearly stated that this would 
be fixed in AFS 3.3. Who's right?

> Dump is location independent at the user level. But butc communicates
> with the dump at a lower level requiring knowledge of the location of
> the volume. 

If vos move can lock a volume's location, so can butc. What is the problem 
here?

> 3.  The TL log does contain a list of volumes that were dumped as does
> the backup database. One should be able to move a volume AFTER it has
> successfully dumped. This would be indicated by the TL log or the backup
> database (using "dumpinfo -id <dumpid>") for the dump in progress. 

Yes, but why should I have to find out the hard way? Why should I have to look 
at this log at all.

> 4. A volume is locked only during the dump of that volume and not for
> the duration of the entire dump. Which is why one is able to move a
> volume while a dump is in progress. 

Then this is incorrect behaviour. Change it. EITHER the volume is required not 
to move until it is backed up - in which case lock it, OR make butc 
intelligent enough to ask the VLDB where the volumes is at the time when it 
needs it so that locks are not required. Just in case anyone argues that the 
wait for each VLDB request slows down the backup, then keep a queue of locked 
volumes (say 10) which are, locked in advance and ready to be backed up, and 
release the locks when they are backed up.

Full backups take a long time here at Cranfield, and I know we're not that big 
a site. Sometimes I *need* to move volumes during a backup. Last week, because 
we were trying our first (stbutc) automated full dump with our new tape 
stacker, I decided not to run balance to even things out, since I knew that 
vos move would almost certainly cause problems. A partition filled up (yes, 
111%) from 92% full in one afternoon, and I had real problems getting it 
working again. Moving volumes, using balance or "by hand" is not something I 
do for fun, it's what keeps our user filestore manageable.

Peter Lister                             Email: [EMAIL PROTECTED]
Computer Centre, Cranfield University    Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK        Fax: +44 234 750875
--- Go stick your head in a pig.  (R) Sirius Cybernetics Corporation ---