[OpenAFS-devel] Re: Backups using commercial products

[John_Morin@transarc.com]

Excerpts from OpenAFS: 4-Jan-101 [OpenAFS-devel] Re: Backups.. David
Thompson@cs.wisc.e (711*)


> In some cases when you do a move, the move completes, but a copy of the .BK 
> volume gets left on the source partition (without any corresponding vldb 
> information).  Not sure about deletes.  Anybody else seen this???

The BK volume is left behind because it contains information you may
want/need. The alternative is to remove the backup volume and then
reclone once the RW has been moved. This is undesirable for those who
want the clone to mean from the last time they cloned the RW (not when
they last moved the RW).

The down side is that the RW no longer has a clone when on its new
partition. And trying to access the clone will fail (unless you move it
back or clone the RW again). The VLDB entry continues to say the BK
exists. A vos syncvldb will warn you whenever it finds one of these
orphaned BK volumes.

I've thought about breaking out the backup volume into its own VLDB
"index entry" so it can then point to its own server and partition. The
concept is not difficult, finding all the places in the code that
assumes the RW entry and BK entry are the same is the hard part :-) I've
also been hesitant to do this until I allow for more then 12 RO volumes.

[A VLDB entry contains an array of server and partition fields where
each of its RW and RO entries exist. This is what  I am referring to
when I talk about a VLDB "index entry" above. The RW index entry and the
BK index entry are one and the same - because AFS makes the assumption
that the BK and RW always exist on the same server and partition.]

> >>On Wed, 3 Jan 2001, Lyle Seaman wrote:
> >>Just out of curiousity what happens now when a backup is in
> >>progress (backup dump or vos dump of a BK volume) and a vos
> >>move or vos remove is issued?  Both of these result in the BK
> >>volume being deleted.  Are they held pending completion of
> >>the backup operation first?

The BK volume is offline so any attempts to delete it would fail. I
don't think the move touches the BK volume so the move would, I believe,
succeed.

	- John Morin.