[OpenAFS] Volume backup in distinct server

[John Rudd]

On Saturday, Jun 21, 2003, at 11:06 US/Pacific, Derek Atkins wrote:

> What you seem to want is ReadWrite replication, which is something
> that AFS does not do.
>

Has anyone thought of adding something like this?  I think it would be 
greatly useful.  Really, while I'd like to see is a live mirror where 
reads come from whichever server is most ready to answer the query and 
writes are simultaneously applied to all mirrors in the cell.  I'm sure 
it's not easy to implement, but I think it would be a welcome addition.


My AFS wish list (to dig up that thread) would be:

a) the above live mirror option,

b) a true journal/checkpoint file system option where you could roll 
back files, etc., to earlier states (and, I have an idea around that, 
where the live disk would be viewed as a cache of the current state, 
and transactions would be mirrored on disk as well as being directly 
dumped to tape, so you could have tapes that span an era of 
transactions as well as traditional tapes that represent snapshots of 
the current data)

c) better NFS/NAMEI support (right now, you can't really navigate the 
NFS volume from which you build the NAMEI volume(s), because the names 
are all obfuscated making it hard to figure out where to restore files 
if you're wanting to do the backups on the NFS side instead of the AFS 
side ... I'd like to see the underlying file system be usable (which 
certainly violates the security model, but that's pretty much true if 
you're using NFS anyway ... but what we want is to use a netapp or 
bluearc file server as the actual physical store for all of the 
advantages you get from that, and then provide the data to outside 
users via AFS; but to make that really work for us, we have to be able 
to do things like easily map the AFS files back to specific NFS files 
for things like restoring and such))

d) an option for "pure krb5" support (no krb4 involved, anywhere ... 
and, as with kerberos, and _option_ for supporting krb4 even though the 
internals are all krb5)