[OpenAFS] Volume backup in distinct server

[Joao Pedro Barreto]

Please correct me, but if I use 'vos addsite', I can only create a 
readonly volume of my read/write volume (when I tried 'vos addsite' with 
the readonly clone, it wasn't allowed). This means that, issuing a 'vos 
release', my read/write volume will be locked for some time, which is 
not desirable.
Am I correct?

Using the following approach, I guess I could avoid this problem: create 
a backup volume on the same server/partition of the original W/R volume, 
then making 'vos dump Myvolume.backup | vos restore backupVol' to 
transfer the contents to a volume on the other server/partition.
Do you agree?

Joao

Derek Atkins wrote:
> "vos addsite"
> "vos release"
> 
> -derek
> 
> Joao Pedro Barreto <jpbarreto@gsd.inesc-id.pt> writes:
> 
> 
>>Hi,
>>
>>But, after creating the clone in the same server/partition as the
>>original volume, how can I copy its contents accross the net to the
>>other server/partition?
>>Is there any way I could do this using exclusively AFS commands? Or do
>>I have to copy everything by my own hands, for example using a simple
>>Unix cp command? And how can I configure it to be periodic, for
>>instance, to be performed daily?
>>
>>The best thing I can think of is to issue a 'vos dump' command to the
>>readonly clones, and piping its output to a 'vos restore' on the other
>>server/partition. Putting this line for each volume I want to backup
>>in a shell script and configure it in chron, I might have my problem
>>solved.
>>Do you find any problems with this solution? Or is there any better
>>approach?
>>
>>Thank you.
>>Joao
>>
>>
>>Derek Atkins wrote:
>>
>>>Hi,
>>>The backup volume is meant for user access to backup data, not for
>>>"replication across servers".  It's on the same server to reduce
>>>the amount of disk space that is used.  It's purpose is not to protect
>>>against lost disks, it's purpose is to protect against "rm".
>>>What you seem to want is ReadWrite replication, which is something
>>>that AFS does not do.
>>>One thing you CAN do is make a RO clone on the same server/partition
>>>as the RW (as well as on the other server).  The local RO clone wont
>>>take up much disk space (it's a clone after all, just like the Backup
>>>volume), but it does help in terms of the locking.  The RW only gets
>>>locked in order to make the clone, and then the clone is copied across
>>>the net.  This means your RW volume isn't locked for the whole release
>>>process, only during the clone.
>>>-derek
>>>Joao Pedro Barreto <jpbarreto@gsd.inesc-id.id> writes:
>>>
>>>
>>>>Hi,
>>>>
>>>>I administer an AFS domain which has two servers storing file volumes.
>>>>I wanted to configure volume backup, so that each volume stored in one
>>>>server's disk would be replicated (or backed up) in the other server's
>>>>disk.
>>>>My first approach was to create read-only replicas of each volume. For
>>>>instance, if a volume was stored in server A, I would create a
>>>>read-only volume for it on server B. However, I soon discovered that
>>>>the release of volumes (which I'd perform daily in order to update the
>>>>read-only volumes) NEEDS TO LOCK the original volume, which can be a
>>>>serious drawback if we consider that most volumes are sufficiently big
>>>>to take some hours to be released.
>>>>I then found about the backup functionality which, according to AFS
>>>>documentation, should be the best choice for my problem. Mainly, this
>>>>solution doesn't require locking of the original volumes to update the
>>>>backup volumes. However, this option only allows creation of backup
>>>>volumes in the SAME PARTITION (AND SERVER) as the original
>>>>volume. Which, of course, is insuficient to my requirements of having
>>>>backup volumes in distinct computers from their original volumes (so
>>>>that, if a computer fails and its data are lost, the volume can still
>>>>be obtainable from the other computer).
>>>>
>>>>Does anyone can help me on this? how should I solve my problem?
>>>>
>>>>Thank you in advance.
>>>>
>>>>Joao
>>>>jpbarreto _AT_ gsd _DOT_ inesc-id _DOT_ id
>>>>
>>>>
>>>>_______________________________________________
>>>>OpenAFS-info mailing list
>>>>OpenAFS-info@openafs.org
>>>>https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>
>>
>