On 11/4/05, Christoph Scheurer <[EMAIL PROTECTED]> wrote:
> Hello,
>
> at our site we are using OpenAFS to serve home-directories for about 60
> users. On Oct 27. we had a hardware failure on an AFS fileserver partition and
> had to restore volume dumps from our backup. The restore procedure finished
> succesfully but when we checked the restored volumes we had to realize that
> some files were missing. Closer inspection showed that these files were
> restored from the most recent full dumps but then removed by restoring the
> subsequent incremental dumps, even that the respective files had not been
> removed between dumps from the original volumes. Has anyone else
> encountered/solved this problem before?

Did you remember to use the "-overwrite incremental" switch when doing
the incremental restore?

> We are running OpenAFS 1.2.13 on the fileserver and the dump/restore is also
> performed on that server locally. Our backup strategy is the following:
>
>  * every night at 0:10 (local time) perform a 'vos backupsys user'
>  * afterwards perform full 'vos dump' for each volume user.*.backup on the 1st
>    of every month
>  * every other day MM/DD/YYYY perform an incremental dump with -time option
>    MM/(DD-1)/YYYY for each volume user.*.backup
>
> Is there a problem with synchronization/serialiation when using 'vos 
> backupsys',
> i.e. should we explicitly 'vos backup' each individual volume before dumping
> it? Or is it better to directly dump the RW volume instead of the RO backup
> copy?

You are doing things the right way.  You don't want to backup the RW
volume so that it stays available for the user.  The RO .backup volume
both provides a way for you to backup files without interupting
service and allows you to make the previous night's backup available
at all times [often by mounting the volume somewhere, such as a
.OldFiles mountpoint in a user's directory].

e.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to