Q Backup Version 2.4

Operator’s Manual Document Revision 1.12

E. Jay Berkenbilt

1 Overview

Q Backup is a software package designed to automate the process of running backups. This software does not actually implement any true backup mechanism such as dump and restore or tar. Instead, it schedules the running of actual backup commands, generates logs, validates success, and issues reports.

Q Backup handles scheduling of what backups are run on what days, what mechanisms are used to perform these backups, and which tapes are used on which days. The backup schedule is based on a one-week cycle with the possibility of specifying any combination of backup sets and levels on each day of the week (including weekends). The tape schedule can include cycles consisting of many weeks. Archiving of tapes for long-term storage can be automated. The setup of the tape schedule is by far the most complex aspect of managing Q Backup, but it is also what makes this software superior to a scheme based on simple shell scripts. The creation of tape schedules is something that is generally done once and then left alone. In addition, several example schedules are provided.

The Q Backup software is fairly general. As of the current version, it supports both backups based on dump and restore and backups based on qsarchive which is in turn based on the Q Synchronization tools. The software is structured in such a way as to make it easy to add new backup modules. For information on using Q Backup, see Chapter 2 [Operation], page 2. For information on extending the backup software, see Chapter 4 [Internals], page 22.

The Q Backup system can be difficult to understand. This manual many not make sense after just one reading. It is strongly recommended that you read and understand Chapter 3 [Examples and Explanations], page 12. If you understand that section, you will probably be in good shape for just about anything you want to do with Q Backup.

2 Operation

2.1 Installing the Software

The Q Backup software is easy to install. The software itself consists of a single top-level script, called backup, and several modules all in a subdirectory called modules. The backup script should be installed in a known location, and the modules directory should be created and populated. The modules directory and the backup script should be in the same directory. Once backup is installed, three symbolic links should be made to it in the same directory: label, what_tape, and contents. Q Backup requires at least Perl version 5.001m. (There is a bug in 5.000 that manifests itself by causing the backup software to reject some properly formatted configuration files. Since the bug was not present with Perl 5.001, no attempt has been made to investigate or fix the problem. In addition, Q Backup uses the strict module, which doesn’t work properly prior to 5.001m.) It is expected that any version of Perl later than 5.001m should also work.

2.2 Basic Concepts

There are a number of basic concepts used by Q Backup. These concepts should be understood before the rest of this will really make sense.

2.2.1 Working Directory

The working directory is the top-level directory containing state information, log information, and temporary space to be used by a given installation of the backup software. The working directory is what defines an installation of the software. (Please note: the actual backup scripts themselves need only be installed once on the system. By installation of the backup software, we mean a collection of systems, backup sets, schedules, etc. being maintained by a single group and using a single tape drive.)

The backup software’s default working directory is ‘/home/dump/hostname’ (where hostname is the name of the machine on which the software is running). It can be overridden from the command line with the --dir option. See Section 2.3 [Running the Software], page 4 for details. The working directory contains three subdirectories: ‘data’, ‘logs’, and ‘tmp’. The ‘logs’ subdirectory contains the subdirectory ‘old’. The ‘logs’ and ‘tmp’ directories (along with their contents) are automatically created by the backup software. The files under ‘data’ have to be created manually and are then either not generally modified, or are maintained automatically by the backup software. For information about these files, see Section 2.4 [Initial Setup], page 6.

2.2.2 Backup Day

A backup day is a day specification format used by the backup software to specify a day of the week for purposes of scheduling backups. It’s form is [+-]day[+-] where day can be one of sun, mon, tue, wed, thu, fri, or sat. A leading + or - means next week or last week. A trailing + or - means the day before or day after. It is also legal to specify today, yesterday, or tomorrow. Weeks go from Sunday to Saturday. A day of the week always refers to that day of this week. For example, if today is Wednesday, then tue refers to yesterday, wed refers to today, and thu refers to tomorrow. Also, +tue refers to next Tuesday, and -thu refers to last Thursday. The trailing + and - for of the backup day specification is primarily intended for use by the software internally. It is a bit smarter than just advancing the day by one—it does so consulting the backup schedule. For example, if today is Friday, and there are no backups scheduled for Saturday or Sunday, then fri+ refers to this coming Monday as does sat+. (sun+ would refer to last Monday because weeks start on Sunday.) Pathological syntaxes such as +fri+ and -mon- are supported. Their meanings are left as an exercise to the reader. It is not supported, however, to specify more than one + or - before or after a backup day.

In general, the human operators of the backup software will use only the leading + or - syntax of the backup day (such as when you need to rerun a backup from last week for some reason) or the unqualified name.

2.2.3 Tape Label

By tape label, we are not referring to the sticky piece of paper that is physically placed on the tape. We are referring instead to the first tape file. This file is a single block containing information about the contents of the tape. It encodes the name, ID, and stage of the tape, the time it was labeled, the backup sets and levels on the tape, and a label format version. To view the label on a tape, simply cat the tape device.

2.2.4 Backup User

The Q Backup software requires that it be run by a user called dump. This user’s name appears in only one place in the backup software, so this could become a configurable option. The dump user should have access to the privileges needed to run whatever backup and restore commands are needed by the backup system.

2.2.5 Tape Identifier

The format of a tape identifier is NAME-ID-STAGE. NAME is an arbitrary string (not containing any - characters!) and is specified in the tape schedule file. (See Section 2.4.5 [Tape Schedule], page 8.) The tape ID is an integer greater than or equal to 1. The stage is a number whose value is maintained by the backup software. The stage of a tape is an indication of how far through its life cycle in the backup system a tape has passed. The purpose of tape stages is to prevent tapes from being unintentionally reused. When the backup software requests a tape for a given day’s backup, it requests it with a stage. If a tape is required at stage n, then any tape whose stage is n or lower accepted. A tape with a higher stage is not accepted. When a tape is accepted, it is relabeled by the backup software with the same name and ID but with a stage equal to one more than the desired stage. This means that if a tape has been used for a backup, and then a request is made to repeat that backup, the tape must be manually relabeled. For some example scenarios, see Chapter 3 [Examples and Explanations], page 12.

2.2.6 Log File

Q Backup puts its log files in the ‘logs’ subdirectory of the working directory. A log file’s name is of the form ‘yy-mm-dd-hhmmss--NAME-ID’ where the date is the time that the backup software was started and the name and ID sections correspond to the tape that was used. When the backup system runs a backup with a tape whose name and ID are NAME-ID, it moves old log files for the same tape into the ‘old’ subdirectory. This way, there should only ever be one file that matches ‘*--NAME-ID’ for a given tape, and that file should be the most recent log file for that tape. If the backup software fails before it successfully verifies the tape label, it writes out its errors in ‘yy-mm-dd-hhmmss--0’. These error files are not moved into the ‘old’ directory.

The log files generally contain enough information to determine what, if anything, went wrong in a given backup run. They consist of planned and actual tape contents as well as concatenated outputs of all the commands used to perform the backups and verifies. In addition, there is extra diagnostic information and occasional time stamps which can be very useful when trying to correlate backup problems with other information in system log files.

2.2.7 Contents File

The contents files are named just like the log files except that they have the string .contents.Z (or .contents.gz or whatever the compression suffix is as specified in the backup parameters file— see Section 2.4.1 [Backup Parameters], page 6) appended to the end of them. They contain a table of contents of each backup written to the tape. These files can often be very large.

2.3 Running the Software

The Q Backup software consists of four commands, which are summarized below. In reality, all four programs are links to the same script, and the program uses the name by which it was invoked to determine functionality.

All commands take the optional arguments --debug, which turns on debugging (debugging can also be enabled by setting the environment variable DEBUG_BACKUP to a non-zero value), and --dir directory which overrides the default working directory. In addition, all commands will give a version number when invoked with --version and a help message when invoked with --help.

2.3.1 backup command

This is the main program in Q Backup. It is the program that actually performs the backups. This program, when invoked with no arguments, attempts to run the backup scheduled for the current day. When run with an argument, the argument is interpreted to be a backup day, and the backup for that day is run instead. The backup software first verifies that the proper tape is in the drive, and if so, generates a table of contents, runs each scheduled backup, verifies the backups, and sends out a mail message indicating whether or not there were errors, what the errors (if any) were, and what tape should go in the drive for the next backup.

2.3.1.1 Automated Operation

Generally, the backup software is automated by running the backup software from cron. It is recommended that the backup process be started before midnight so that the backup days specified in the schedule files are what users expect. (It is generally considered to be more intuitive to load the tape for Friday’s backup on Friday rather than on Thursday.) If the backup software is run from cron, then, under normal circumstances, the only maintenance required is for someone to respond daily to the mail messages the software sends out telling them what tape to load into the drives. Once the schedules are set up, all the tape rotation and scheduling will be handled automatically.

2.3.1.2 Manual Operation

There are cases in which the backup software needs to be run manually. Examples include when a backup needs to be rerun because the proper tape was not loaded, because of a holiday, because of the failure of an important backup due to a down machine, or for any number of other reasons. In this case, all that is necessary is that the designated dump user invoke the backup command specifying the desired backup day.

2.3.2 label command

This command is used to label a tape. Under ordinary circumstances, tapes need to be labeled only before their initial use. It is possible to relabel tapes with the label command when necessary, however. The label command can be run in one of two ways: either by specifying a tape identifier (optionally without the tape name which defaults to the one specified in the tape schedule file if not specified) or by specifying a backup day. If a tape identifier is given, the stage should be omitted and will be set to zero. If a backup day is specified, the tape is labeled with whatever label is desired for the given day. The recommended use of label is to specify the backup day since this is the least error-prone method.

2.3.3 what tape command

This command takes a backup day as an argument and issues a message indicating what tape should be loaded for that day.

2.3.4 contents command

This command is rarely used. To use it, insert a tape containing a good backup in the drive, and specify the name of a contents file. A contents file is then generated for that tape. This can be useful to recover the contents of a tape whose contents files was erased or damaged for some reason. It should never have to be used under ordinary circumstances.

2.4 Initial Setup

When the programs of Q Backup run, they have the notion of a working directory. This directory defaults to ‘/home/dump/hostname’ where hostname is the name of the host on which you are running the commands. It can be overridden on the command line. For details, see Section 2.2.1 [Working Directory], page 2. All the configuration files needed to run the backup software are in a subdirectory of the working directory called ‘data’.

The initial setup of Q Backup requires that several files be created. These files include a general backup parameters file, an initial current state file, a group of backup sets (lists of entities to be backed up), a backup schedule (telling what is backed up on what day), and a tape schedule (telling which tapes to use on which days).

All the configuration files used by Q Backup, except for backup sets, consist of key-value pairs. Each entry in each file is a key and a value separated by a colon. White spaces serves as argument separators but is otherwise ignored. Blank lines are ignored. The # symbol is the comment character. Comment characters may occur anywhere on a line.

2.4.1 Backup Parameters

The backup parameters file is called ‘data/backup_params’ (relative to the working directory). There are five supported keys of which two are required. The keys are as follows:

site_name

This key specifies an arbitrary site name. The site name is used in log files and mail messages from the backup software and as output from some commands. It is for the convenience of the operators and is just a symbolic name for a given installation of the backup software. This is a required key.

tape_device

This key specifies what tape device will be used for this backup. The first word of the value of this key must be a tape device specification. The following arguments are specific to the tape device type used. For information about supported tape device types, see Section 2.5 [Supported Tape Devices], page 9. This is a required key.

backup_mail

If specified, this key indicates electronic mail addresses to which the backup software should send status reports. It defaults to root. You may put anything that is a valid mail To field including comma-separated addresses.

compress_cmd

This key, if specified, gives the name of a command to be used to compress backup contents files. The default value is compress.

compress_sfx

This key, if specified, names the suffix that is expected to be appended to the contents file after it is compressed. The default value is .Z. This is used in renaming old logs and in informing the operator of the location of the contents file.

Here is an example backup parameters file:

     site_name: PRIMARY
     backup_mail: operator@my.domain
     compress_cmd: gzip
     compress_sfx: .gz
     tape_device: simple dev /dev/rmt/0cn finish rewind

2.4.2 Current State

The backup software keeps some state about where in the backup cycle it currently is. This information is stored in the current state file which is located in ‘data/current_state’. This file must be manually created for each new backup installation, but should never subsequently have to be edited—the backup software keeps it up-to-date automatically. However, it is safe to edit this command if you know what you are doing. The current state file contains the following keys:

last_updated

This key’s value is a date of the form yy-mm-dd. It will still work after the year 2000. (Maybe it will break in the year 2070. It is at the mercy of the localtime call.) The date must refer to a Sunday. It should be the date of the Sunday that starts the current week. The backup software uses this to keep track of when weeks change so that it knows when to update the other fields in this file. This key should be left out of the file when first created. The backup software will automatically initialize it when it is first run.

this_week

This key’s value is a number from 1 to however many weeks there are in the backup cycle. It is used to calculate which tape to insert. When the current state file is initially created, it’s value should be 1. For more information about the tape schedule, see Section 2.4.5 [Tape Schedule], page 8.

id_offset.

This key’s value is a non-negative integer. It is added to tape identifiers in the tape schedule file during the computation of the current desired tape. For more information about the tape schedule, see Section 2.4.5 [Tape Schedule], page 8.

When the backup software is set up for the first time, the current state file should look like this:

     this_week: 1
     id_offset: 0

2.4.3 Backup Sets

Backup sets (known as dump sets in older versions of the software) are files that specify groups of entities to be backed up as a unit. Each backup set resides in a file by the same name as the backup set. A backup set called SET_A resides in the file ‘data/backup_sets/SET_A’. The backup sets files are the only ones that are not key-value pairs. However, blank lines and comments are handled as in all the other files. Each entry in the backup set file is a directive whose first word is the name of a backup module and whose other words are given as arguments to the specified backup module. For details about what can be in this file, see Section 2.6 [Supported Backup Modules], page 10.

2.4.4 Backup Schedule

The backup schedule file, which resides in ‘data/schedule/backup’, indicates which backup sets at which levels should be performed on which days of the week. The days of the week can be specified as mon, tue, wed, thu, fri, sat, or sun. No day has to be specified. If a day is not specified, no backup is scheduled for that day, and it is an error to try to run that day’s backup. The value for each day of the week is a concatenated list of backup sets and levels. Here is an example of a backup schedule file:

     mon: A 0 B 5
     tue: B 0 A 5
     wed: A 5 B 5
     thu: B 5 A 5
     fri: A 5 B 5

For explained examples, see Chapter 3 [Examples and Explanations], page 12.

2.4.5 Tape Schedule

The tape schedule file is the most complex part of the backup system. It is very difficult to explain this without a lot of detailed examples, so the full explanation will be deferred to Chapter 3 [Examples and Explanations], page 12. This file resides in ‘data/schedule/tape’. The following keys are supported:

weeks This key’s value is the number of weeks in the tape cycle.

tapes This key’s value is the number of new tapes introduced each cycle, or, equivalently, the number of tapes that are archived in each cycle.

archive_stage

This key’s value is the tape stage that indicates a tape is ready to be archived. Once a tape hits that stage, the backup software refuses to write to the tape. Its presence is primarily for the protection of the users of the backup software.

tape_name

This key’s value is the tape name assigned to each tape identifier. It does not have to be the same as the site name specified in the backup parameters file (see Section 2.4.1 [Backup Parameters], page 6), but it is often convenient for it to be the same. The purpose of this key is to allow unique identification of each tape so that tape n in one installation of the backup software cannot be mistaken for tape n in another installation.

In addition to the above entries, there should be an entry in this file for each weekday for which there is an entry in the backup schedule file. Each weekday entry should have a value consisting of the same number of fields as weeks in the tape cycle (as specified by the weeks key in this file). Each argument should be a tape identifier (see Section 2.2.5 [Tape Identifier], page 3) without the name. To compute the tape for a given day, the id_offset and this_week fields of the current state file and the row in the tape schedule file for the given day are consulted. The identifier in the column corresponding to the value of this_week is taken, and the ID portion of the identifier is incremented by id_offset.

For example, suppose we had the following tape schedule:

     weeks: 2
     tapes: 1
     archive_stage: 10
     tape_name: TEMP
     mon: 04-00 04-02
     tue: 03-04 03-06
     wed: 04-01 04-03
     thu: 03-05 03-07
     fri: 02-08 01-09

If the contents of the current state file are as follows:

     this_week: 2
     id_offset: 23

and if today is Wednesday, then the desired tape for today is TEMP-27 at stage 3. The reason is that, since this is Wednesday of week 2, we look in the second column of data after wed. We see 04-03, which means tape 4 at stage 3. Since our id_offset is currently 23, we add 23 to 4 giving us an ID of 27. Since our tape_name is TEMP, our desired tape is TEMP-27 at stage 3.

The weeks and tapes entries in the tape schedule file control the updating of the this_week and id_offset entries in the current state file. Specifically, each week, this_week is incremented. When its value exceeds weeks, it is reset to 1 and the value of tapes is added to id_offset. The manifestation of this is that, as time goes on, lower-numbered tapes are no longer asked for. This is how the backup software automatically archives tapes—it simply stops asking for tapes once they are ready to be archived. Another manifestation of this is that a tape with a given ID will be active in the backup system for several cycles. To trace a tape’s life in the system, one needs to trace its use in one cycle, and then, to trace its life in the next cycle, look in the schedule for the tape whose ID is its ID minus the current id_offset in the current state file. This is explained with an example in Chapter 3 [Examples and Explanations], page 12.

2.5 Supported Tape Devices

2.5.1 Simple Tape Device

The simple tape device corresponds to your ordinary single-tape tape drive. When configuring the backup system to use the simple tape device, the tape_device entry in the backup parameters has five arguments (See Section 2.4.1 [Backup Parameters], page 6 for information about the backup parameters file.) The first is the word simple, indicating that the simple device should be used. The remaining arguments are dev followed by the tape device name and finish followed by the mt command that should be used to indicate that the backup has been finished. The non-rewinding form of the tape device should always be used for the backup software.

Suppose that you wanted to indicate that the tape device ‘/dev/rmt/0cn’ should be used for the backups and that the mt rewind command should be issued when the backup completed. To achieve this, you would put the following line in your backup parameters file:

     tape_device: simple dev /dev/rmt/0cn finish rewind

Suppose that you wanted to use ‘/dev/nrst17’ as the tape device and that you wanted mt offline to be issued at the end of a backup. In this case you would use the following specification:

     tape_device: simple dev /dev/nrst17 finish offline

2.6 Supported Backup Modules

2.6.1 Dump Backup Module

The dump backup module uses the standard dump and restore commands to perform backups and verifications. (Some operating systems call these ufsdump and ufsrestore). When using this backup module, the specification of each backup in the backup set file has the form

     dump host:/file/system [dump_command[:rdump_command] [stupid]]

The keyword dump at the beginning of the line indicates that the dump backup module should be used. host:/file/system indicates that the path ‘/file/system’ should be dumped from host host. The rest of the line is optional. If no dump command is specified, then ‘/usr/etc/dump’ and ‘/usr/etc/rdump’ are used for local file systems and remote file systems respectively. If ufsdump is given as the dump command, then ‘/usr/sbin/ufsdump’ is used for both local and remote dump. If anything else is given, it must start with ‘/’. In this case, it indicates the absolute pathname of the dump command if there are no colons in the string, or the absolute path name of the local dump command and the absolute pathname of the remote dump command separated by a colon. In all cases, the name of the restore program (used during the verify step) is generated by replacing the string “dump” with the string “restore” in both the local and remote dump commands. If the word stupid appears at the end of the line, it means that the remote dump command cannot handle a device specification of the form user@host:/dev/whatever and instead

just accepts host:/dev/whatever.

Here are several examples. If you wanted to specify ‘icarus:/local’ in a backup set and specify that it should be backed up with ‘/usr/etc/dump’ or ‘/usr/etc/rdump’, you would use the entry

     dump icarus:/local

If you wanted to specify that ‘soup:/opt’ should be dumped with the ufsdump command, you could use the entry

     dump soup:/opt ufsdump

If you wanted to indicate that ‘teal:/usr’ should be backed up using

‘/usr/local/etc/suid_dump’ and ‘/usr/local/etc/suid_rdump’ as the local and remote dump

commands, you could use the entry

     dump teal:/usr /usr/local/etc/suid_dump:/usr/local/etc/suid_rdump

Finally, if you wanted to indicate that ‘zorgon:/’ should be backed up using ‘/etc/dump’ or ‘/etc/rdump’, and that the rdump command does not accept user@host:/device, you would use the entry

     dump zorgon:/ /etc/dump:/etc/rdump stupid

2.6.2 QsArchive Backup Module

The qsarchive backup module uses programs called qsa_dump and qsa_restore to perform backups. When using this backup module, the specification of each backup in the backup set file is of the form

     qsarchive host /directory [extra arguments for qsa_dump]

As of qbackup version 2.3, the qsarchive backup module can be used to back up SMB shares (Windows 95/NT). In order to use this feature, specify the directory as a share name. The following syntax is used: [user[/pass]@]//host/service[:dir]. Note that the share is specified with forward slashes rather than backslashes. If user is specified, it will be used as the netbios username with which to connect to the share. If pass is specified, it will be used as a password for the share. If dir is specified, it will be treated as a subdirectory of the share, and will be considered the root for purposes of backing it up. This feature doesn’t work very well at present. It is best to create a separate share if you wish to restrict backups to a subdirectory of a share. Since user, pass, and dir are all optional, the simplest form //user/pass is accepted.

The fact that a password has to be specified in the clear in the backup set file is a known security problem. If necessary, a fix can be implemented. For now, if the password used to access the share is sensitive, then the backup sets and logs should be kept unreadable. In order to eliminate this problem, code would be changed so that printing of the password would be suppressed in any logfile or temporary file, the password would not have to appear in the backup set file, but could instead be looked up in a separate read-protected file based on the share name and/or username, and all programs involved would suitably modify the way the appear to ps to prevent passwords from being trivially stolen while the backup is actually running. Please feel free to suggest other measures that should be taken. At the moment, the attitude being taken is that someone with access to the backup server probably has access to the machines being backed up, and certainly has access to the backups, so a user who would steal a backup password has little to gain that he/she does not already have. The best policy for now would be to create separate shares for use by backup only, and assign them passwords that are different from any other passwords in the system.

In order to use the qsarchive backup module, it is necessary to have the entire qsync package installed in one of the standard directories in qbackup’s path, such as ‘/usr/local/bin’. As of qbackup version 2.3, qsync version 1.5b is required. As of qsync 1.5, make_sync, apply_sync, qsa_ dump, and qsa_restore are included in the qsync distribution along with the ‘qsutil_modules’ directory, which must be installed in the same directory as the other programs. There is an addition program called qsfiles_from_samba, which is required if Samba support is to be used. As of release 1.6.19 patch level 9 of samba, a patch, also included in the qsync distribution is required. This patch should be applied, and them smbclient should be rebuilt.

3 Examples and Explanations

Once the basic concepts of Q Backup are understood, a working operational knowledge is best obtained by studying some examples. There are examples here to help clarify both the configuration process and the day-to-day operation of the backup software.

3.1 Example Configurations

3.1.1 Initial Configuration

Suppose you have a network consisting twelve machines containing a total of ten gigabytes of disk space that needs to be backed up, and that you have a single five-gigabyte tape drive. Suppose also that you wish to have on hand at any one time level zero backups for the last four weeks and incremental backups allowing you to reconstruct the system at any day in the last week. Finally, suppose that you wish to set aside an archive copy of the entire system once every four weeks. We will describe how to achieve this configuration given this situation. Once we have done this, a number of alternatives and possible modifications will also be discussed.

First, here’s a detailed description of the network. We have a main server called server, which has an internal 500-megabyte drive consisting of a 32-megabyte root partition, a 200-megabyte ‘/usr’ partition, and an additional 150-megabyte partition. There are also three other one-gigabyte partitions. Additionally, there is a smaller server called helper that has the same configuration for its internal drive, and one additional one-gigabyte partition. Also, there are ten client workstations each with 500 megabytes of disk space. These machines are called client1 through client10. Here is a table of the disk space usage on the network:

FILE SYSTEM     SPACE
server:/        32
server:/usr     200
server:/u/0     150
server:/u/1     1000
server:/u/2     1000
server:/u/3     1000
helper:/        32
helper:/usr     200
helper:/u/0     150
helper:/u/1     1000
client1:/       32
client1:/usr    200
client1:/u/0    150
 .
 .
 .
client10:/      32
client10:/usr   200
client10:/u/0   150

The tape drive is connected to the helper. Here are the steps needed to configure Q Backup for this network.

Create a user called dump with a home directory in /home/dump. Make sure that the user dump has rsh permission to all the other machines on the network. Install the backup software in ‘/home/dump’. Create a directory called ‘/home/dump/helper’. This will be the working directory for this installation of the backup software. Create a subdirectory called ‘data’. Now create the configuration files in the ‘data’ directory.

Creation of the Current State File

Creation of the ‘current_state’ file in ‘data/current_state’ is completely deterministic. The initial current state file should be as follows:

     this_week: 1
     id_offset: 0

Creation of the Backup Parameters File

The backup parameters file is ‘data/backup_params’. Suppose we have gzip available as a compression program^{1}. Suppose that we would like to eject the tape automatically after a completed backup, and that the tape device we are going to use is ‘/dev/nrst16’. Finally, suppose that the user potato will be changing tapes and monitoring the backup system for this site. The following ‘backup_params’ file will be used:

     site_name: SAMPLE
     backup_mail: potato
     compress_cmd: gzip
     compress_sfx: .gz
     tape_device: simple dev /dev/nrst16 finish offline

Creation of backup sets

With only a five-gigabyte tape drive, it will not be possible to ever give everything on the network a level zero backup on a single day. In order to make sure everything gets a level zero backup one a week and at least an incremental backup once a day, let’s create a schedule with three days in which some level zero backups are performed and two days in which only incrementals are performed. We will need to set up backup sets then corresponding to each group of machines based on which day they get their level zero backups on. In addition, system disks are generally less important than spare partitions that could contain data. Therefore, we will also separate our backup sets into data and system. This can all be achieved with the following six backup sets. Note that we are going to use the dump backup module for each backup. For information about the options available to us based on what kinds of systems these are, see Section 2.6.1 [Dump Backup Module], page 10. We are calling these backup sets A_DATA, A_SYS, B_DATA, B_SYS, C_DATA, and C_SYS. The backup set files themselves reside in files by these names under the directory ‘data/backup_sets’. More descriptive names for the backup sets might be useful on a real network, though these names are often fine if backups are divided up solely based on size and not based on any other categorizations.

1 gzip is a compression program from the free software foundation. It is superior to compress and is available from any gnu archive site, such as prep.ai.mit.edu:pub/gnu.

# This is backup set A_DATA
dump server:/u/1
dump server:/u/2
# This is backup set A_SYS
dump server:/
dump server:/usr
dump client1:/
dump client1:/usr
dump client2:/
dump client2:/usr
dump client3:/
dump client3:/usr
# This is backup set B_DATA
dump server:/u/3
dump helper:/u/1
# This is backup set B_SYS
dump helper:/
dump helper:/usr
dump client4:/
dump client4:/usr
dump client5:/
dump client5:/usr
dump client6:/
dump client6:/usr
# This is backup set C_DATA
dump server:/u/0
dump helper:/u/0
dump client1:/u/0
dump client2:/u/0
dump client3:/u/0
dump client4:/u/0
dump client5:/u/0
dump client6:/u/0
dump client7:/u/0
dump client8:/u/0
dump client9:/u/0
dump client10:/u/0
# This is backup set C_SYS
client7:/
client7:/usr
client8:/
client8:/usr
client9:/
client9:/usr
client10:/
client10:/usr

Notice that all the *_DATA backup sets are about the same size, and that all the *_SYS backup sets are about the same size. Although this can be difficult to achieve in a real network, the closer you can come to this, the better you will be. Ideally, you should also try to arrange for the backup sets to be about the same in terms of how fast they change so that incrementals of each backup set will be about the same size.

The reasoning for the above distribution of file systems will make more sense as you study the backup schedule.

Creation of the backup schedule

Our backup schedule will contain three days in which level zero backups are performed. It doesn’t really matter which three days are picked, so we will choose Wednesday, Thursday, and Friday, with the main server’s level zero backups done on Friday. (This way, when system administrators need to do weekend maintenance, there will be a very recent level zero backup already available.) Let’s assume no backups are done on the weekends. Thus, we can start out with the following:

     mon:
     tue:
     wed: C_DATA 0 C_SYS 0
     thu: B_DATA 0 B_SYS 0
     fri: A_DATA 0 A_SYS 0

Now we need to make sure that everything gets an incremental backup. Let’s give each set two level three backups followed by two level six backups. This way, no more than two incremental tapes will be needed to reconstruct a full system, and the incremental dumps won’t get as large as if we used the same level for all incrementals. This gives us the following:

     mon: A_DATA 3 A_SYS 3 B_DATA 3 B_SYS 3 C_DATA 6 C_SYS 6
     tue: A_DATA 3 A_SYS 3 B_DATA 6 B_SYS 6 C_DATA 6 C_SYS 6
     wed: C_DATA 0 C_SYS 0 A_DATA 6 A_SYS 6 B_DATA 6 B_SYS 6
     thu: B_DATA 0 B_SYS 0 A_DATA 6 A_SYS 6 C_DATA 3 C_SYS 3
     fri: A_DATA 0 A_SYS 0 B_DATA 3 B_SYS 3 C_DATA 3 C_SYS 3

Finally, let us reorder the backups on each day so that whatever is getting a level zero dump is first on the tape, and otherwise, *_DATA always comes before *_SYS and backup sets get equal opportunity to be near the beginning of the tape. This minimizes risk under conditions in which backups partially fail because of full or damaged tapes. This leaves us with the following backup schedule:

     mon: C_DATA 6 B_DATA 3 A_DATA 3 C_SYS 6 B_SYS 3 A_SYS 3
     tue: C_DATA 6 B_DATA 6 A_DATA 3 C_SYS 6 B_SYS 6 A_SYS 3
     wed: C_DATA 0 C_SYS 0 A_DATA 6 B_DATA 6 A_SYS 6 B_SYS 6
     thu: B_DATA 0 B_SYS 0 A_DATA 6 C_DATA 3 A_SYS 6 C_SYS 3
     fri: A_DATA 0 A_SYS 0 B_DATA 3 C_DATA 3 B_SYS 3 C_SYS 3

There are reasons that one may wish to have these in other orders, of course. For example, if it is known that C_DATA doesn’t really contain anything of terrible importance, then it would not really be sensible to put it earlier on the tape than A_DATA and B_DATA.

Creation of the tape schedule

As mentioned, the creation of the tape schedule is the most complicated part of the backup configuration process. Fortunately, the process generally has to be done only once for a given installation, and there are several examples in this document. We will step through the process of creating a tape schedule that is compatible with the above backup schedule and that meets the constraints set forth at the start of this exercise. As a reminder, those constraints were that we always had four weeks of level zero backups available, archived tapes once every four weeks, and always had enough incremental backups on hand to reconstruct the system for any day in the last week.

Let’s start with the easy part of the tape schedule file: the parameters explaining our tape cycle. The top of our tape schedule file will be as follows:

     weeks: 4
     tapes: 3
     archive_stage: ??
     tape_name: SAMPLE

At this stage of the development of the tape schedule, we do not yet know what the archive will be, so we’ll leave an invalid value in its place as a reminder. We know that we are on a four-week cycle, so weeks must be 4. We know that we will be archiving three tapes in each cycle because that is the number of days each week during which level zero backups are performed. Therefore, we set tapes to 3. The tape_name is an arbitrary string, so we’ll choose SAMPLE since that’s what this is. Now we are ready for the hard part: the creation of the actual tape schedule. We know that the tape schedule will have to have entries for the five normal working days since that’s what the backup schedule has, and we know that we will need four columns since that’s how many weeks we have. Let’s start out then with a template we can fill in.

     mon: __-____-____-____-__
     tue: __-____-____-____-__
     wed: __-____-____-____-__
     thu: __-____-____-____-__
     fri: __-____-____-____-__

As time progresses, the backup software will ask for tapes with higher numbers since id_offset in the current state file will be increased by tapes every weeks weeks. This means that the archive tapes will be given low numbers. Let’s start out by filling in our archive tapes for Wednesday, Thursday, and Friday of week four.

     mon: __-____-____-____-__
     tue: __-____-____-____-__
     wed: __-____-____-__03-__
     thu: __-____-____-__02-__
     fri: __-____-____-__01-__

Now, we know that we need to have the last three weeks’ level zeroes on hand at all times, so that means that we cannot reuse the same tapes on other Wednesdays, Thursdays, or Fridays in this cycle. This means we will have to use different tape numbers for the other weeks. Filling those in gives us this:

     mon: __-____-____-____-__
     tue: __-____-____-____-__
     wed: 12-__09-__06-__03-__
     thu: 11-__08-__05-__02-__
     fri: 10-__07-__04-__01-__

Now we’re ready for incrementals. Since we need to be able to reconstruct any day in the last week, we need different level incremental tapes for Mondays and Tuesdays. However, since we only have to go back one week, we can reuse the same tape for each Monday and for each Tuesday. Filling this in gives us the following:

     mon: 14-__14-__14-__14-__
     tue: 13-__13-__13-__13-__
     wed: 12-__09-__06-__03-__
     thu: 11-__08-__05-__02-__
     fri: 10-__07-__04-__01-__

This represents a completed schedule with no stages filled in. It shows that we have fourteen tapes in the system at any one time, and that we consume three tapes ever four weeks. However, since we are going to be introducing three tapes into the system every four weeks regardless, it would be better (but not required) to have a multiple of three tapes in the system. Doing so just means that tapes will get more even use. Adding a fifteenth tape will add no long-term cost to the backup system, but will add some additional ability to retrieve older backups. Let’s add the extra tape as an incremental tape replacing tape 14 every other week. This brings us to our final tape schedule (still without stages):

     mon: 15-__14-__15-__14-__
     tue: 13-__13-__13-__13-__
     wed: 12-__09-__06-__03-__
     thu: 11-__08-__05-__02-__
     fri: 10-__07-__04-__01-__

That means that our initial cost includes buying fifteen tapes plus three tapes for each additional month. If we wanted to start off with a six-month supply of tapes, have to buy thirty tapes. For the next six-month period, however, only an additional eighteen will be needed.

Now we must fill in the tape stages. To do this, we must understand the life of each tape as it passes through the backup system. It is very helpful to understand how the backup system determines what tape to ask for on a given day. This is covered in Section 2.4.5 [Tape Schedule], page 8. Let us start off with the current state file in its initial state: with id_offset equal to 0 and this_week equal to 1. Since the number of tapes in our system is a multiple of tapes, let us consider the life of the highest-numbered tape in the system: tape 15^{2}. The first time tape 15 is requested is on Monday of week 1. We will make this stage zero. The next time it is requested will be Monday of week 3. We will make this stage 1. This gives us the following so far:

     mon: 15-00 14-__15-01 14-__
     tue: 13-__13-__13-__13-__
     wed: 12-__09-__06-__03-__
     thu: 11-__08-__05-__02-__
     fri: 10-__07-__04-__01-__

Tape 15 is not requested again in this four-week cycle. In week five, however, this_week in the current state file has been reset to 1, and id_offset has been increased from 0 to 3. That means that tape 15 actually corresponds to a 12 in the tape schedule. (This is the confusing part.) That means that the next time tape 15 is really requested will be Monday of week five. Week five corresponds to week 1 on the schedule but with the id_offset increased by tapes. This means

2 The life of tape 1 is not particularly interesting—it is used once and then archived. This is really an artifact of the startup process. Tapes 13, 14, and 15 are the first three tapes to actually go through an entire normal life in the backup system. If you don’t understand this right now, just accept it on blind faith for now. that the stage for Wednesday of week 1 should be 2. Tape 12 does not appear in the cycle again, so the next time tape 15 will be requested, it will be in the third cycle when it will correspond to 9 in the schedule. On Wednesday of week ten, this tape will once again be requested, so this stage will be 3. Continuing in this fashion, we can trace this tape’s life through the system as it corresponds to 15, 12, 9, 6, and 3 in the schedule. Doing this gives us the following:

mon: 15-00 14-__15-01 14-__
tue: 13-__13-__13-__13-__
wed: 12-02 09-03 06-04 03-05
thu: 11-__08-__05-__02-__
fri: 10-__07-__04-__01-__

Now we repeat this exercise for tape 14 which will correspond to 14, 11, 8, 5, and 2 in the schedule. Stepping through this, we have the following:

mon: 15-00 14-00 15-01 14-01
tue: 13-__13-__13-__13-__
wed: 12-02 09-03 06-04 03-05
thu: 11-02 08-03 05-04 02-05
fri: 10-__07-__04-__01-__

Finally, we trace 13 through the system and end up with this:

mon: 15-00 14-00 15-01 14-01
tue: 13-00 13-01 13-02 13-03
wed: 12-02 09-03 06-04 03-05
thu: 11-02 08-03 05-04 02-05
fri: 10-04 07-05 04-06 01-07

This would actually be a fully complete schedule, but it has an undesirable attribute: tapes don’t all get to archive status at the same stage. To work around this problem, we recall that it is okay to skip stages since, when stage n is requested, any stage equal to n or lower is acceptable. This is discussed in Section 2.2.5 [Tape Identifier], page 3. To even things out, we can increase stages of tapes 15 and 14 at strategic points. Consider the following final version of the schedule:

mon: 15-00 14-01 15-02 14-03
tue: 13-00 13-01 13-02 13-03
wed: 12-04 09-05 06-06 03-07
thu: 11-04 08-05 05-06 02-07
fri: 10-04 07-05 04-06 01-07

Note that the first time tape 14 is asked for, the backup system asks for it at stage 1 instead of stage 0. However, this is okay, because tape 14 at stage 0 will do fine. Likewise with the other skipped stages. Now that we have finished the hard part of designing the tape schedule, we know the one piece of missing information: the archive stage. After tapes 1, 2, and 3 are written, they will be at stage 8. We want the software to label these tapes as archive tapes so that they will never again be accepted by the backup system (even if, say, at some future date, we change this around so that something could be asked for at stage 8). This is for our future protection. To achieve this, we set archive_stage to 8 giving us the final complete schedule:

weeks: 4
tapes: 3
archive_stage: 8
tape_name: SAMPLE

mon: 15-00 14-01 15-02 14-03
tue: 13-00 13-01 13-02 13-03
wed: 12-04 09-05 06-06 03-07
thu: 11-04 08-05 05-06 02-07
fri: 10-04 07-05 04-06 01-07

One final cosmetic note: tape IDs and stages are integers. Leading zeroes are ignored. They are present here just to make things line up nicely in the file.

3.1.2 First Modification

Suppose that we decide that fifteen tapes is too great a startup cost and that we don’t really need four weeks of level zeroes on hand. Suppose that we can get by with only two weeks of level zeroes. Let’s see how that effects us. Given these constraints, we can use the following schedule (stages omitted):

mon: 09-__08-__09-__08-__
tue: 07-__07-__07-__07-__
wed: 06-__03-__06-__03-__
thu: 05-__02-__05-__02-__
fri: 04-__01-__04-__01-__

Notice that the week one level zero tapes are reused on week three and the week two tapes are reused on week four. This change reduces our working tape set from 15 to 9—a savings of six tapes at startup. There is no change in maintenance cost—three new tapes are still needed every four weeks. Going through a similar exercise as above, we end up with the following complete schedule:

weeks: 4
tapes: 3
archive_stage: 8
tape_name: SAMPLE
mon: 09-00 08-01 09-02 08-03
tue: 07-00 07-01 07-02 07-03
wed: 06-04 03-06 06-05 03-07
thu: 05-04 02-06 05-05 02-07
fri: 04-04 01-06 04-05 01-07

3.1.3 Second Modification

Now suppose that we could rearrange our backup sets and backup schedules so that we only needed two days of level zero backups. Let us consider the following schedule with stages omitted:

weeks: 4
tapes: 2
archive_stage: ??
tape_name: SAMPLE
mon: 08-__07-__08-__07-__
tue: 06-__06-__06-__06-__
wed: 05-__05-__05-__05-__

thu: 04-__02-__04-__02-__
fri: 03-__01-__03-__01-__

Filling in the stages, we have this:

weeks: 4
tapes: 2
archive_stage: 10
tape_name: SAMPLE
mon: 08-00 07-00 08-01 07-01
tue: 06-02 06-03 06-04 06-05
wed: 05-02 05-03 05-04 05-05
thu: 04-06 02-08 04-07 02-09
fri: 03-06 01-08 03-07 01-09

In this system, there are eight active tapes at one time, and two new tapes are added every four weeks. No skipping of stages is required, and the archive stage is 10. This means that each tape actually gets used more times. Since there are eight tapes, each tape survives for sixteen weeks. Each tape starts its life as a Monday tape where it used twice. Even number tapes then serve as Tuesday tapes for four weeks, and then spend eight weeks as Thursday tapes. Odd numbered tapes serve as Wednesday tapes and then as Friday tapes.

3.1.4 Third Modification

Here’s a trivial case in which no archive is done at all and in which we need two weeks of backups on hand at all times:

weeks: 2
tapes: 0
archive_stage: 2
tape_name: SAMPLE
mon: 10-00 05-00
tue: 09-00 04-00
wed: 08-00 03-00
thu: 07-00 02-00
fri: 06-00 01-00

Note that in this case, the archive stage is set to a higher stage than is ever obtained. Thus, no tapes are archived. When tapes is zero, the backup software does not increment stages, so they are effectively not used.

3.2 Example Operation

For all examples here under example operation, we will assume the configuration files set up under the initial situation (see Section 3.1.1 [Initial Configuration], page 12).

3.2.1 Normal Automated Operation

Once the configuration files are all set up, the dump user needs a crontab entry to run backups automatically on the desired days. The following cron entry would run backup at 11:00 p.m. on Monday through Friday.

     0 23 * * 1-5 /home/dump/backup

Next, the new tapes intended for the backup system should be labeled. Suppose today is Monday. When you run /home/dump/what_tape while logged into helper, you will get the output

     Backup site SAMPLE requires tape SAMPLE-15 at stage 0 on mon (this week).

Now you should pick a tape to be SAMPLE-15 and label it. The easiest way to label it is to put it in the drive and run label today. Alternatively, you could say label 15 or label SAMPLE-15.

At this point, all you have to do is wait for the backup software to run and send mail with its results.

3.2.2 Wrong Tape Inserted

Suppose the wrong tape had been inserted in the drive by mistake, and it was desirable to run Monday night’s backup manually on Tuesday when you came in. In this case, you simply need to obtain Monday’s tape, insert it, and as the user dump, run /home/dump/backup mon &. If this happened on a Friday, and you had to run Friday’s backup manually on the following Monday, you would have to run /home/dump/backup -fri since you would be referring to last Friday. For information about specification of backup days, see Section 2.2.2 [Backup Day], page 2.

3.2.3 Major Backup Failure

Suppose the right tape was in the drive but server crashed in the middle of being backed up, so the backup didn’t contain important file systems. In this case, the tape was already relabeled with an increased stage, and would therefore be rejected if you just ran /home/dump/backup mon on Tuesday. This means you will have to relabel the tape first. To do this, type /home/dump/label mon first, and then, when that finishes, run /home/dump/backup mon. This should, of course, be done with Monday’s tape still in the drive.

3.2.4 Alternative Working Directory

Suppose helper goes down for some reason, and you need to run backups from client2 instead. It is not necessary to rename directories or make any other configuration changes. Also, suppose /home/dump was local to helper, and you have helper’s /home disk mounted on ‘/mnt’. You could create the following crontab entry for dump on client2:

     0 23 * * 1-5 /mnt/dump/backup -dir /mnt/dump/helper

You could use this form of the backup command to rerun backups manually as well.

4 Internals

The Q Backup software is designed to be easily extensible by someone with familiarity with objects in Perl version 5. This section of the document attempts provide a simple roadmap to the software so that it can be more easily extended. For greatest understanding of the details, it is best to read the code and the comments contained within it. However, every effort will be made to have this documentation provide complete and accurate descriptions of all external object interfaces needed for extension of the software.

4.1 Backup Modules

The Q Backup software can support any number of backup modules. A backup module called module must be implemented in a module called BackupModule_module. All backup modules must be derived from the type BackupModule. The name of the backup module to be used for a given backup is the first argument of that backup’s entry in the backup set file. See Section 2.4.3 [Backup Sets], page 7 for details. The specified backup module is ultimately created by having its new method called with the backup level as the first argument followed by the list of strings following the module name in the the backup set file.

A backup module is expected to be able to generate a unique description of the file system (or whatever) that is being backed up. It must support the concept of levels, but it doesn’t have to do anything with them. Generally, a level n backup catches everything that has changed since the last backup of level less than n. This way, a level zero backup is a full backup, and other backups are incremental.

Each backup module must support the following methods:

new This routine takes as arguments a level followed by a list of strings as appear on the specification of the backup in the backup set file. It is up to the backup module how to interpret these strings. This routine returns a blessed object. The object must also be able to be treated as a BackupModule object which has been created with the same arguments as were passed to this routine.

backup This routine takes a tape device as an argument and attempts to perform the backup the owning object specifies writing to the tape device in question. It returns one

          of three exit codes: $BackupModule::success, $BackupModule::rsh_failure, or

$BackupModule::cmd_failure. The first status code indicates success. The second indicates that a running a remote command was attempted, but that the rsh command was not successful so the remote command was never actually attempted. The third indicates that the the command was run locally and failed or that the command was run remotely and, although the rsh command succeeded, the remote command failed. In the event of this response code, the backup software uses a possible change in the modification of the tape device to indicate whether or not the backup command actually wrote to the tape or not. Although this method is not 100% reliable, it seems to be fine for the normal case and most failure modes as well, and there doesn’t seem to be anything better than that that is sufficiently general to support multiple backup modules.

equal This routine should take a second object of the same type and return a boolean value indicating whether or not the two objects are equal. unparse This routine should return a string that describes the given backup module. Its output

appears in the tables of contents.

unparse_description

This routine should return a string that describes the description block for the backup performed by the given backup module. Its output appears in the tables of contents.

verify This routine expects the tape to be positioned right before the start of the backup it describes. It’s job is to determine whether the next file on the tape is the expected backup and to make sure that the backup is good if possible. It takes two arguments: the tape device and a type glob whose file handle entry is the backup contents file. If at all possible, this routine should append the contents of the backup to this file.

4.2 Tape Devices

The Q Backup software can support any number of tape device types. A tape device type called devtype must be implemented in a module called TapeDev_devtype. Assuming that the tape device behaves like a normal tape, it is convenient to derive this type from TapeDev which implements all of these routines. However, this is not really necessary. The tape device to be used by a given run of the backup software is given in the ‘backup_params’ file. (See Section 2.4.1 [Backup Parameters], page 6 for details on this file.) The specified tape device is created by having its new method called with the list of strings following the device name in the the backup parameters file. The TapeDev module’s new method takes two arguments: the name of the actual tape device, and the argument to mt that should be used after a successful backup completion. There is no reason that a tape device implementation has to be derived from TapeDev as long as it supports the required interface. Each tape device must support the following methods:

new This routine must construct a tape device of the given type. It takes a list of arguments corresponding to the strings in the backup parameters file, and returns a blessed object.

device This routine takes no arguments and returns the name of the tape device file. This routine should be used sparingly by the backup software. Sometimes, however, the name of the device is needed as an argument to the underlying program that does the backup and restore operations. The backup software also checks the modification time of this device to see whether the software has written to the device.

finish This routine is called after completion of the backup. It can be used to perform whatever kind of cleanup may be desired or needed. Examples would include rewinding or ejecting the tape.

fsf This command takes a single argument and fast-forwards the tape device by that number of tape files.

read This routine reads an entire tape file and returns it as a string. It removes any trailing nulls that may end the string. It is generally used to read contents blocks and the like.

rewind This routine rewinds the tape device.

status This routine should try to determine the status of the tape device. It is expected to call die if the status is bad. This routine should be called in an eval statement, and $@ should be checked to determine failure. write This routine writes a string, passed as its only argument, to the tape device. It may

do such things as round up to a multiple of the device’s blocksize. This routine should be able to accept any string.

Index 25

Index

A

archive state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

B

backup command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 backup day specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 backup modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 backup modules, dump and restore. . . . . . . . . . . . . . . . . 10 backup modules, qsarchive . . . . . . . . . . . . . . . . . . . . . . . . . 10 backup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 backup schedule file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 backup sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 backup user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 backup params . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 BackupModule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

C

compress command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 compress suffix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 contents command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 current state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 current week . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

D

dump backup module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 dump sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 dump user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

E

electronic mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

I

ID offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

L

label command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 last updated time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 log file compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

O

overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Q

qsarchive backup module. . . . . . . . . . . . . . . . . . . . . . . . . . . 10

S

simple tape device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 site name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 status notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

T

tape device specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 tape devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 tape devices, simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 tape identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 tape mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 tape name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 tape schedule file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 TapeDev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 tapes per cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 this week . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

W

weeks per cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 what tape command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 wrong tape inserted. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Table of Contents

1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Installing the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Basic Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2.1 Working Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2.2 Backup Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2.3 Tape Label. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.4 Backup User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.5 Tape Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.6 Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.7 Contents File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Running the Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3.1 backup command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3.1.1 Automated Operation . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1.2 Manual Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.2 label command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.3 what tape command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.4 contents command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Initial Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.1 Backup Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.2 Current State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.3 Backup Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.4 Backup Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.5 Tape Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Supported Tape Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1 Simple Tape Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.6 Supported Backup Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.1 Dump Backup Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6.2 QsArchive Backup Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Examples and Explanations . . . . . . . . . . . . . . . . . . . . 12

3.1 Example Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1 Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2 First Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.3 Second Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.4 Third Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Example Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.1 Normal Automated Operation . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.2 Wrong Tape Inserted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.3 Major Backup Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.4 Alternative Working Directory. . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Backup Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Tape Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25