[OpenAFS-devel] mutiple levels of backup volumes?

[Neulinger, Nathan R.]

Finally getting back to looking at this. I should have a test cell up
shortly that I'm willing to try some of this stuff on. 

I was looking at the code in vos that creates the backup volumes, etc. and
it doesn't look like it would be a very big deal at all to modify it to
allow creating secondary backup volumes. 

Keeping track of them though is the issue.

What I wonder though is - could some of the 'multiple residency' support be
leveraged to keep track of multiple backup volumes as well as multiple
read-write volumes, or is that all being done externally? I haven't really
looked at it yet.

If I were to go ahead and modify vos to allow creating secondary backup
volumes - I presume that shouldn't be a problem with our existing vldb/etc.
even though the vldb won't be keeping track of the volumes? I assume that
the extra backup volumes though will not get cleaned up when I do a move, so
I'd need to clean them up myself with a vos zap. 

Any ideas?

Basically, what we were thinking is having a daily .backup (current code),
and then also maintaining one each day for the past few days. Granted, that
means you have to have more disk space, but disk space is alot cheaper than
user/staff time to do restores. 

-- Nathan

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]
> Sent: Monday, November 06, 2000 3:20 PM
> To: Neulinger, Nathan R.
> Cc: 'openafs-devel@central.org'
> Subject: Re: [OpenAFS-devel] mutiple levels of backup volumes?
> 
> 
> On Mon, 6 Nov 2000, Neulinger, Nathan R. wrote:
> 
> > How hard would it be to give the AFS server the ability to 
> have multiple
> > levels of backup volumes? i.e. be able to maintain a 
> history of volumes. 
> 
> It should be possible to create an arbitrary number of RO 
> clones of the
> same read/write volume.  However, the vldb tracks only one 
> backup and one
> readonly clone for any given volume.  You'd have to invent 
> some scheme for
> naming the extra backup volumes, and some mechanism for tracking them.
> 
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>