[OpenAFS] Preserving server info

Marcus Watts mdw@spam.ifs.umich.edu
Fri, 22 Jun 2007 16:23:51 -0400


> Date:    Fri, 22 Jun 2007 13:15:43 EDT
> To:      OpenAFS Information <openafs-info@openafs.org>
> From:    Jon Allen Boone <ipmonger@delamancha.org>
> Subject: [OpenAFS] Preserving server info
> 
> Folks,
> 
>    I have an OpenAFS setup running here at home.
> 
>    My /vicexx partitions are on external firewire drives so that they  
> can easily be moved to a new machine in the event that my server  
> dies.  My concern is that there are some files and/or databases that  
> need to be duplicated in order to protect against losing the server's  
> internal drive.  Which files should I be backing up to ensure that I  
> can bring up my OpenAFS setup on a new machine (or the same machine  
> with a new hard drive)?  Or should I just go through the process of  
> setting up the cell from scratch?
> 
> --jon

Per fileserver, you should also save sysid
	If you don't save sysid, you'll need to do "vos syncvldb" and maybe
	"vos syncserv" to put things right.  This is slow, but otherwise
	fairly harmless.
	This file does not change with use.

Cell-wide, you should save KeyFile .
	If you don't save this, you'll have to generate it;
	not necessarily a big deal.
	This file does not change with use.
You probably want to save CellServDB and you may as well save ThisCell ,
although those are not strictly speaking essential data.

On your db server, you should preserve the contents of
	/usr/afs/db/*
which might be called
	/var/lib/openafs/db/*
		vldb.* could instead be recovered with "vos syncvldb".
		prdb.* has no easy recovery method.  Do back this up.
These files do change with use.

You should certainly also save your kerberos database.  You
are presumably not using kaserver.  This too has no easy recovery
alternative.

You may also want to consider how you intend to backup your
actual afs file data.  "vos dump" is at least a start.
Volume data generally has no easy recovery method, although replicated
read-only volumes can be of use for special cases.

				-Marcus Watts