Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

OpenAFS/backup system

From Livedoc - The Documentation Repository
Revision as of 23:06, 27 January 2008 by Brandon Vargo (bot) (talk | contribs) (Robot: Changing Category:Obsolete)
Jump to: navigation, search


The OpenAFS backup system consists of three main programs: buserver, backup, and butc. Currently, the system is being used to backup all web, user, and service volumes to tapes on the Exabyte EXB-480 Tape Drive.


The buserver is a daemon which keeps track of the "backup database," which contains all information about what dumps have been performed, the dumping schedule, and what volumes go on what dumps. It also knows what dumps are on what tapes, and keeps track of what port offsets are on which server. This is just added in BosConfig; no configuration necessary just for the server.


To write a backup dump to a tape, there must be a butc process running for that specific tape device. The butc process coordinates obtaining the correct tape for writing, and getting volume dumps, etc. as well as writing to the tape. They also can display information about what's going on, so it's generally a good idea to run butc where you can observer output. Right now, butc processes for emperor are run in a screen session, so we can check up on them at any time. The butc process will also prompt an operator to insert a certain tape manually if automatically getting the correct tape fails for some reason.


The backup command suite has several commands to run.

Dump scheduling

 adddump         add dump schedule
 deldump         delete dump schedule
 listdumps       list dump schedules
 setexp          set/clear dump expiration dates

A dump schedule isn't really a "schedule" per se. A dump "schedule" basically just consists of a dump level, and long until it expires. For example, some of our dump schedules include:

 /sunday0  expires in  27d
     /Mon  expires in  6d
     /Tue  expires in  6d
     /Wed  expires in  6d
     /Thu  expires in  6d
     /Fri  expires in  6d
     /Sat  expires in  6d

Which are named pretty intuitively. The '/sunday0' schedule is a full dump, and usually occurs every four weeks (as you can see, it expires in 27 days, making it so the backup system prevents anything from overwriting a /sunday0 backup dump until 27 days have passed). The other levels (which are actually /sunday0/Mon and so on; backup just doesn't repeat all of that) are incremental dumps, ecah one only recording the information changed since the last /sunday0 dump. These dump schedules only expire in 6 days, so it's possible to overwrite them in just a week (which is what we do).

Hosts and port offsets

 addhost         add host to config
 delhost         delete host to config
 listhosts       list config hosts

When performing a backup dump, a "port offset" must be specified. A port offset determines both the host to contact, and what tape device that host uses. (See tapeconfig furthur down on this page.) Use these commands to specify which host corresponds to a certain port offset.

Volume sets

 addvolentry     add a new volume entry
 addvolset       create a new volume set
 delvolentry     delete a volume set sub-entry
 delvolset       delete a volume set
 listvolsets     list volume sets

A volume set is what it sounds like: just a set of volumes. A volume set is defined by a series of volume entries. A volume entry is an entry specifying what volume to backup, and on what server and partition. The volume name, partition, and server can all be simple regular expressions (the only special characters are brackets, dots, backslashes, and asterisks), so you can specify large amounts of volumes with a single volume entry.

Dumping and restoring

 deletedump      delete dumps from the database
 diskrestore     restore partition
 dump            start dump
 restoredb       restore backup database
 savedb          save backup database
 scantape        dump information recovery from tape
 volrestore      restore volume
 volsetrestore   restore a set of volumes

The "dump" command starts a backup dump for the specified volume set and dump schedule and port offset. If you use the "-append" switch, instead of overwriting the data on the tape (which it would normally do if the data was expired), it just appends to it.

The *restore commands just restore volumes from tape from a few different methods (either specifying the specific volume, or restoring a whole disk, or restoring a whole volume set).

The *db commands deal with backing up the backup database itself. If somehow all of the backup database is lost (which seems rather unlikely, since it's retained across all of the dbservers via ubik), you can restore it from tape with those commands. You can also get the database information for a single dump by using 'scantape' on a tape with the dump on it. (So you can then restore it afterwards.)

"deletedump" just deletes the information from the backup database about a certain dump. The actual data on the tape remains intact, so you can still restore it later with "scantape".


 apropos         search by help text
 dbverify        check ubik database integrity
 dumpinfo        provide information about a dump in the database
 help            get help on commands
 interactive     enter interactive mode
 jobs            list running jobs
 kill            kill running job
 labeltape       label a tape
 quit            leave the program
 readlabel       read the label on tape
 status          get tape coordinator status
 volinfo         query the backup database

Most of these either have obvious functions or aren't used very often. The "jobs" refer to something like a backup dump running. "readlabel" can possibly tell you what data is on a tape, if any, and "labeltape" can be used to assign your own label to a tape. Reasons for why you'd want to do that are either nonexistant or just for advanced users; check the OpenAFS documentation.


Under Debian, configuration for the backup system occurs in /var/lib/openafs/backup/ (as well as logging). Here are the various files that live there:


This is a very simple file, which maps tape devices to port offsets, optionally with tape sizes and filemark sizes. As of the time of this writing, it contains the following (on emperor):

 /dev/st0        0
 /dev/st1        1
 /dev/st2        2
 /dev/st3        3

Since the Exabyte has four tape drives in it, this just maps them to port offsets 0-4. As of the time of this writing, only port offsets 1 and 2 are used for backups; the others are left for fiddling around with tapes, or possible for use with AMANDA in the future. (Some AMANDA tape changers only use the first drive, which is why we're not using it for the OpenAFS backups.)

Optionally, there can be a third and fourth column with are the tape size and filemark size, but it works fine (and is even recommended in the manual) to leave them blank to their defaults. The only time it would be advisable to set the size is when the tapes are very small (<2GB), so butc doesn't spend all of it's time writing a volume, only to find that it wasn't large enough to fit on the tape. Our tapes are 20 GB (more with compression, obviously), so we don't need to worry about this.


This is the configuration file used for the tape device device_name. If the tape device was /dev/foo/bar, then the configuration filename would be CFG_foo_bar. As of now, we're only using /dev/st0 through /dev/st3, so we have the config files CFG_st0 through CFG_st3. Since they are all Exabyte drives and are all used the same way, they're all symlinked to the same configuration file: CFG.exabyte.


The configuration file for exabyte drives. Right now it just contains the following:

 MOUNT /usr/local/lib/openafs/exabyte-mount
 UNMOUNT /usr/local/lib/openafs/exabyte-unmount

The first line makes sure that butc asks for a tape the first time it tries to load one in a dump set. If AUTOQUERY is set to NO, then it assumes the correct tape is already in there (which is useful for manual loading of tapes, but we don't do that, since we have the Exabyte).

The second and third lines specify the location of the mounting and unmounting scripts to use for load/unloading tapes from the tape changer. Documentation for these scripts can be found at exabyte-mount; they just call mtx and mt to load/unload the requested tape.


Using the same device_name convention as CFG, these files are where errors are logged by butc.


Using the same device_name convention as CFG, these files are where all butc operations are logged.