![[Return to Library]](../books.gif)
![[Contents]](../toc.gif)
![[Previous Topic]](../prev.gif)
![[Bottom of Topic]](../bot.gif)
![[Next Topic]](../next.gif)
![[Index]](../index.gif)
The AFS Backup System helps you to create backup copies of data from AFS volumes and to restore data to the file system if it is lost or corrupted. This chapter explains how to configure the Backup System. For instructions on backing up and restoring data and displaying dump records, see Backing Up and Restoring AFS Data.
This chapter explains how to perform the following tasks by
using the indicated commands:
| Determine tape capacity and filemark size | fms |
| Define Tape Coordinator entry in Backup Database | backup addhost |
| Remove Tape Coordinator entry from Backup Database | backup delhost |
| Display Tape Coordinator entries from Backup Database | backup listhosts |
| Create volume set | backup addvolset |
| Add volume entry to volume set | backup addvolentry |
| List volume sets and entries | backup listvolsets |
| Delete volume set from Backup Database | backup delvolset |
| Delete volume entry from volume set | backup delvolentry |
| Define dump level | backup adddump |
| Change expiration date on existing dump level | backup setexp |
| Delete dump level from dump hierarchy | backup deldump |
| Display dump hierarchy | backup listdumps |
| Label tape | backup labeltape |
| Read label on tape | backup readlabel |
The AFS Backup System is highly flexible, enabling you to control most aspects of the backup process, including how often backups are performed, which volumes are backed up, and whether to dump all of the data in a volume or just the data that has changed since the last dump operation. You can also take advantage of several features that automate much of the backup process.
To administer and use the Backup System most efficiently, it helps to be familiar with its basic features, which are described in the following sections. For pointers to instructions for implementing the features as you configure the Backup System in your cell, see Overview of Backup System Configuration.
When you back up AFS data, you specify which data to include in terms of complete volumes rather than individual files. More precisely, you define groups of volumes called volume sets, each of which includes one or more volumes that you want to back up in a single operation. You must include a volume in a volume set to back it up, because the command that backs up data (the backup dump command) does not accept individual volume names.
A volume set consists of one or more volume entries, each of which specifies which volumes to back up based on their location (file server machine and partition) and volume name. You can use a wildcard notation to include all volumes that share a location, a common character string in their names, or both.
For instructions on creating and removing volume sets and volume entries, see Defining and Displaying Volume Sets and Volume Entries.
A dump is the collection of data that results from backing up a volume set. A full dump includes all of the data in every volume in the volume set, as it exists at the time of the dump operation. An incremental dump includes only some of the data from the volumes in the volume set, namely those files and directory structures that have changed since a specified previous dump operation was performed. The previous dump is referred to as the incremental dump's parent dump, and it can be either a full dump or an incremental dump itself.
A dump set is a collection of one or more dumps stored together on one or more tapes. The first dump in the dump set is the initial dump, and any subsequent dump added onto the end of an existing dump set is an appended dump. Appending dumps is always optional, but maximizes use of a tape's capacity. In contrast, creating only initial dumps can result in many partially filled tapes, because an initial dump must always start on a new tape, but does not necessarily extend to the end of the tape. Appended dumps do not have to be related to one another or to the initial dump (they do not have to be dumps of the same or related volume sets), but well-planned appending can reduce the number of times you have to change tapes during a restore operation. For example, it can make sense to append incremental dumps of a volume set together in a single dump set.
All the records for a dump set are indexed together in the Backup Database based on the initial dump (for more on the Backup Database, see The Backup Database and Backup Server Process). To delete the database record of an appended dump, you must delete the initial dump record, and doing so deletes the records for all dumps in the dump set. Similarly, you cannot recycle just one tape in a dump set without deleting the database records of all tapes in the dump set.
For instructions on creating an initial dump, see Backing Up Data, and to learn how to append dumps, see Appending Dumps to an Existing Dump Set.
A dump hierarchy is a logical structure that defines the relationship between full and incremental dumps; that is, it defines which dump serves as the parent for an incremental dump. Each individual component of a hierarchy is a dump level. When you create a dump by issuing the backup dump command, you specify a volume set name and a dump level name. The Backup System uses the dump level to determine whether the dump is full or incremental, and if incremental, which dump level to use as the parent.
You can associate an expiration date with a dump level, to define when a dump created at that level expires. The Backup System refuses to overwrite a tape until all dumps in the dump set to which the tape belongs have expired, so assigning expiration dates automatically determines how you recycle tapes. You can define an expiration date either in absolute terms (for example, 13 January 2000) or relative terms (for example, 30 days from when the dump is created). You can also change the expiration date associated with a dump level (but not with an actual dump that has already been created at that level).
For instructions on creating dump hierarchies, assigning expiration dates, and establishing a tape recycling schedule, see Defining and Displaying the Dump Hierarchy.
When you create a dump, the Backup System creates a Backup Database record for it, assigning a name comprising the volume set name and the last element in the dump level pathname:
volume_set_name.dump_level_name
For example, a dump of the volume set user at the dump level /sunday/friday is called user.friday. The Backup System also assigns a unique dump ID number to the dump to distinguish it from other dumps with the same name that possibly exist.
The Backup System assigns a similar AFS tape name to each tape that contains a dump set, reflecting the volume set and dump level of the dump set's initial dump, plus a numerical index of the tape's position in the dump set, and a unique dump ID number:
volume_set_name.dump_level_name.tape_index (dump ID)
For example, the second tape in a dump set whose initial dump is of the volume set uservol at the dump level /sunday/friday has AFS tape name like uservol.friday.2 (914382400).
In addition to its AFS tape name, a tape can have an optional permanent name that you assign. Unlike the AFS tape name, the permanent name does not have to indicate the volume set and dump level of the initial (or any other) dump, and so does not change depending on the contents of the tape. The Backup System does not require a certain format for permanent names, so you need to make sure that each tape's name is unique. If a tape has a permanent name, the Backup System uses it rather than the AFS tape name when referring to the tape in prompts and the output from most backup commands, but still tracks the AFS tape name internally.
Every tape used in the Backup System has a magnetic label at the beginning that records the tape's name, capacity, and other information. You can use the backup labeltape command to write a label, or the backup dump command creates one automatically if you use an unlabeled tape. The label records the following information:
If a tape does not already have an actual AFS tape name when you write a dump to it, the Backup System constructs and records the appropriate AFS tape name. If the tape does have an AFS tape name and you are writing an initial dump, then the name must correctly reflect the dump's volume set and dump level.
For information about labeling tapes, see Writing and Reading Tape Labels.
In addition to the tape label, the Backup System writes a dump label on the tape for every appended dump (the tape label and dump label are the same for the initial dump). A dump label records the following information:
The Backup System writes a filemark (also called an End-of-File or EOF marker) between the data from each volume in a dump. The tape device's manufacturer determines the filemark size, which is typically between 2 KB and 2 MB; in general, the larger the usual capacity of the tapes that the device uses, the larger the filemark size. If a dump contains a small amount of data from each of a large number of volumes, as incremental dumps often do, then the filemark size can significantly affect how much volume data fits on the tape. To enable the Backup System to factor in filemark size as it writes a dump, you can record the filemark size in a configuration file; see Configuring the tapeconfig File.
A Tape Coordinator machine is a machine that drives one or more attached tape devices used for backup operations. It must run the AFS client software (the Cache Manager) but reside in a physically secure location to prevent unauthorized access to its console. Before backup operations can run on a Tape Coordinator machine, each tape device on the machine must be registered in the Backup Database, and certain files and directories must exist on the machine's local disk; for instructions, see To configure a Tape Coordinator machine.
Each tape device on a Tape Coordinator machine listens for backup requests on a different UNIX port. You pick the port indirectly by assigning a port offset number to the tape device. The Backup System sets the device's actual port by adding the port offset to a base port number that it determines internally. For instructions on assigning port offset numbers, see Configuring the tapeconfig File.
For a tape device to perform backup operations, a Backup Tape Coordinator (butc) process dedicated to the device must be running actively on the Tape Coordinator machine. You then direct backup requests to the device's Tape Coordinator by specifying its port offset number with the -portoffset argument to the backup command.
In addition to writing backup data to tape, you can direct it to a backup data file on the local disk of a Tape Coordinator machine. You can then to transfer the data to a data-archiving system, such as a hierarchical storage management (HSM) system, that you use in conjunction with AFS and the Backup System. A backup data file has a port offset like a tape device. For instructions on configuring backup data files, see Dumping Data to a Backup Data File.
The Backup Database is a replicated administrative database maintained by the Backup Server process on the cell's database server machines. Like the other AFS database server processes, the Backup Server uses the Ubik utility to keep the various copies of the database synchronized (for a discussion of Ubik, see Replicating the AFS Administrative Databases).
The Backup Database records the following information:
The backup suite of commands is the administrative interface to the Backup System. You can issue the commands in a command shell (or invoke them in a shell script) on any AFS client or server machine from which you can access the backup binary. In the conventional configuration, the binary resides on the local disk.
The backup command suite provides an interactive mode, in which you can issue multiple commands over a persistent connection to the Backup Server and the Volume Location (VL) Server. Interactive mode has several convenient features, including the following:
Before issuing a command that requires reading or writing a tape (or backup data file), you must also open a connection to the Tape Coordinator machine that is attached to the relevant tape device (or that has the backup data file on its local disk), and issue the butc command to initialize the Tape Coordinator process. The process must continue to run and the connection remain open as long as you need to use the tape device or file for backup operations.
For further discussion and instructions, see Using the Backup System's Interfaces.
Before you can use the Backup System to back up and restore data, you must configure several of its basic components. The indicated sections of this chapter explain how to perform the following configuration tasks:
If you have already configured all of the components required for performing a backup dump or restore operation, you can proceed to the instructions in Backing Up Data and Restoring and Recovering Data.
Several factors interact to determine how much data the Tape Coordinator can fit on a tape:
(The amount of data that can fit in a backup data file is determined by amount of space available on the partition, and the operating system's maximum file size. The Tape Coordinator does not write filemarks when writing to a backup data file. For further information about configuring a Tape Coordinator to write to a backup data file, see Dumping Data to a Backup Data File.)
As the Tape Coordinator (butc) process initializes, it reads the /usr/afs/backup/tapeconfig file on its local disk to learn the tape capacity and filemark size (for a tape device) or the file size (for a backup data file) to use for dump operations. When you begin a dump operation, the Tape Coordinator also reads the tape or backup data file's label to see if you have recorded a different tape capacity or file size. If you have, the value on the label overrides the default value from the tapeconfig file.
As the Tape Coordinator writes data to a tape during a dump operation, it uses the capacity and filemark information to track how much tape it has used and how much remains before the physical end-of-tape (EOT). Shortly before reaching EOT, the Tape Coordinator stops writing and requests a new tape. Similarly, it uses a backup data file's size to know when it is about to exhaust the space in the file. If the Tape Coordinator reaches the EOT unexpectedly, it recovers by obtaining a new tape and writing to it the entire contents of the volume it was writing when it reached EOT. The interrupted volume remains on the first tape, but is never used.
Many tape devices use tapes that can accommodate multiple gigabytes, or even multiple terabytes, of backup data, especially if you use the device's compression mode. When writing to such devices and tapes, allowing the Tape Coordinator to hit the EOT unexpectedly is generally recommended. The devices write data so quickly that it usually does not take much extra time to rewrite the interrupted volume on the new tape. Similarly, they compress data so well that the data abandoned on the first tape from the interrupted volume does not constitute a waste of much tape.
When writing to tapes that accommodate a smaller amount of data (say, less than two GB), it is better to avoid having the Tape Coordinator hit EOT unexpectedly. AFS supports volumes up to 2 GB in size, so an interrupted volume can in fact take up most of the tape. For such tapes, recording accurate values for tape capacity and filemark size, if possible, helps to maximize both use of tape and the efficiency of dump operations. The following discussion of the fields in the tapeconfig file explains how to determine the appropriate values.
Use a text editor to create an entry in a Tape Coordinator's tapeconfig file for each tape device or backup data file that it uses. Each device or file's entry is on its own line and has the following format:
[capacity filemark_size] device_name port_offset
where
To determine the capacity of a tape under two GB in size that you are going to use in regular (noncompression) mode, you can either use the value that the tape's manufacturer specifies on the tape's packaging or use the fms command to calculate the capacity, as described later in this section. To avoid having the Tape Coordinator reach the EOT unexpectedly, it is best to record in the tapeconfig file or on the label a capacity that is about 10% smaller than the actual capacity of the tape. To calculate the appropriate value for a small tape used in compression mode, one method is to multiply the tape capacity (as recorded by the manufacturer) by the device's compression ratio.
For tapes that hold multiple gigabytes or terabytes of data, or if using a tape drive's compression mode, the recommended configuration is to record a value quite a bit (for instance, two times) larger than the maximum amount you believe can fit on the tape. It is not generally worthwhile to run the fms command on large tapes, even in noncompression mode. The command definitely does not yield accurate results in compression mode. The Tape Coordinator is likely to reach the EOT unexpectedly, but compression mode fits so much data on the tape that the data abandoned from an interrupted volume does not represent much of the tape's capacity.
For a backup data file, record a value slightly smaller than the amount of space available on the partition, and definitely smaller than the operating system's maximum file size. It is also best to limit the ability of other processes to write to the partition, to prevent them from using up the space in the partition.
If this field is empty, the Tape Coordinator uses the maximum acceptable value (2048 GB or 2 TB). Either leave both this field and the filemark_size field empty, or provide a value in both of them.
For a tape device in regular (noncompression) mode, you can use the fms command to determine filemark size, or use the value reported by the device's manufacturer. To help the Tape Coordinator avoid reaching EOT unexpectedly, increase the value by about 10% when recording it in the tapeconfig file.
The recommended value for a tape device in compression mode is 0 (zero). The fms command does not yield accurate results in compression mode, so you cannot use it to determine the filemark size.
The recommended value for a backup data file is also 0 (zero). The Tape Coordinator does not use filemarks when writing to a file, but a value must appear in this field nevertheless if there is also a value in the capacity field.
If this field is empty, the Tape Coordinator uses the value 0 (zero). Either leave both this field and the capacity field empty, or provide a value in both of them.
Legal values are the integers 0 through 58510 (the Backup System can track a maximum of 58,511 port offset numbers). Each value must be unique among the cell's Tape Coordinators, but you do not have to assign port offset numbers sequentially, and you can associate any number of them with a single machine or even tape device. For example, if you plan to use a device in both compression and noncompression mode, assign it two different port offsets with appropriate tape capacity and filemark values for the different modes.
Assign port offset 0 (zero) to the Tape Coordinator for the tape device or backup data file that you use most often for backup operations; doing so enables you to omit the -portoffset argument from the largest possible number of backup commands.
The following example tapeconfig file includes entries for two tape devices, /dev/rmt0h and /dev/rmt1h. Each one uses tapes with a capacity of 2 GB and has a filemark size of 1 MB. Their port offset numbers are 0 and 1.
2g 1m /dev/rmt0h 0 2G 1M /dev/rmt1h 1
The fms command reports the capacity of the tape you have inserted and the tape device's filemark size, both on the standard output stream (stdout) and in its fms.log file, which it writes in the current working directory. The command interpreter must write data to the entire tape, so running the command can take from several hours to more than a day, depending on the size of the tape.
% fms <tape special file>
where
The following example output reports that the tape in the device with device name /dev/rmt0h has a capacity of 2136604672 bytes (about 2 GB), and that the device's filemark size is 1910205 bytes (close to 2 MB).
% fms /dev/rmt0h wrote block: 130408 Finished data capacity test - rewinding wrote 1109 blocks, 1109 file marks Finished file mark test Tape capacity is 2136604672 bytes File marks are 1910205 bytes
Each person who issues the backup and butc commands in your cell must be listed in the /usr/afs/etc/UserList file on every database server machine that stores the Backup Database and Volume Location Database (VLDB), and every machine that houses a volume included in a volume set. By convention, the UserList file is the same on every server machine in the cell; the instructions in this document assume that your cell is configured in this way. To edit the UserList file, use the bos adduser and bos removeuser commands as described in Administering the UserList File.
In addition to being listed in the UserList file, backup operators who issue the butc command must be able to write to the files stored in each Tape Coordinator machine's local /usr/afs/backup directory, which are protected by UNIX mode bits. Before configuring your cell's first Tape Coordinator machine, decide which local user and group to designate as the owner of the directory and the files in it. Among the possible ownership options are the following:
Another option is to define a group in the local group file (/etc/group or equivalent) to which all backup operators belong. Then turn on the w mode bit (write permission) in the group mode bits rather than the user mode bits of the /usr/afs/backup directory and files in it. An advantage over the methods listed previously is that each operator can retain an individual administrative account for finer granularity in auditing.
For instructions on implementing your choice of protection methods, see Configuring Tape Coordinator Machines and Tape Devices.
This section explains how to configure a machine as a Tape Coordinator machine, and how to configure or remove the Tape Coordinator associated with a single tape device or backup data file.
| Note: | When configuring a tape device attached to an AIX system, you must set the device's tape block size to 0 (zero) to indicate variable block size. If you do not, it is possible that devices attached to machines of other system types cannot read the tapes made on the AIX system. Use the AIX smit program to verify or change the value of the tape block size for a tape device, as instructed in Sep 3. |
% bos listusers <machine name>
% su root Password: root_password
If the Tape Coordinator machine is an AIX system, issue the following command to change the tape device's tape block size to 0 (zero), which indicates variable block size. Repeat for each tape device.
# chdev -l 'device_name' -a block_size='0'
where device_name is the tape device's device name (for example, /dev/rmt0h).
# ls /usr/afsws/etc
# mkdir /usr/afs # mkdir /usr/afs/backup
# chown admin_owner /usr/afs/backup # chown admin_owner /usr/afs/backup/tapeconfig # chgrp admin_group /usr/afs/backup # chgrp admin_group /usr/afs/backup/tapeconfig # chmod 774 /usr/afs/backup # chmod 664 /usr/afs/backup/tapeconfig
# backup addhost <tape machine name> [<TC port offset>]
where
% bos listusers <machine name>
% su root Password: root_password
If the Tape Coordinator machine is an AIX system, issue the following command to change the tape device's tape block size to 0 (zero), which indicates variable block size.
# chdev -l 'device_name' -a block_size='0'
# backup listhosts
where listh is the shortest acceptable abbreviation of listhosts.
# backup addhost <tape machine name> [<TC port offset>]
% bos listusers <machine name>
% backup delhost <tape machine name> [<TC port offset>]
where
% backup listhosts
where
The output lists each Tape Coordinator machine and the port offset numbers currently allocated to it in the Backup Database. The appearance of a port offset number does not imply that the associated Tape Coordinator is actually running. Machine names appear in the format in which they were specified with the backup addhost command.
The following example output lists the Tape Coordinators currently defined in the Backup Database of the ABC Corporation cell:
% backup listhosts
Tape hosts:
Host backup1.abc.com, port offset 0
Host backup1.abc.com, port offset 2
Host backup2.abc.com, port offset 1
Host backup2.abc.com, port offset 3
The Backup System handles data at the level of volumes rather than individual files. You must define groups of volumes called volume sets before performing backup operations, by using the backup addvolset command. A volume set name can be up to 31 characters long and can include any character other than the period (.), but avoid using metacharacters that have special meanings to the shell.
After creating a volume set, use the backup addvolentry command to place one or more volume entries in it. They define the volumes that belong to it in terms of their location (file server machine and partition) and name. Use the command's required -server argument to designate the file server machine that houses the volumes of interest and its required -partition argument to designate the partition. Two types of values are acceptable:
For the volume name (the required -volume argument), specify a combination of alphanumeric characters and one or more metacharacters to specify part or all of the volume name with a wildcard. You can use any of the following metacharacters in the volume name field:
Perhaps the most common regular expression is the period followed by an asterisk (.*). This expression matches any string of any length, because the period matches any character and the asterisk means any number of that character. As mentioned, it is the only acceptable regular expression in the file server and partition fields of a volume entry. In the volume name field, it can stand alone (in which case it matches every volume listed in the VLDB), or can combine with alphanumeric characters. For example, the string user.*\.backup matches any volume name that begins with the string user and ends with .backup.
Issuing the backup addvolentry command in interactive mode is simplest. If you issue it at the shell prompt, you must surround any string that includes a regular expression with double quotes (" ") so that the shell passes them uninterpreted to the backup command interpreter rather than resolving them.
To define various combinations of volumes, provide the following types of values for the backup addvolentry command's three arguments. The list uses the notation appropriate for interactive mode; if you issue the command at the shell prompt instead, place double quotes around any string that includes a regular expression. To create a volume entry that includes:
As you create volume sets, define groups of volumes you want to dump to the same tape at the same time (for example, weekly or daily) and in the same manner (fully or incrementally). In general, a volume set that includes volumes with similar contents (as indicated by similar names) is more useful than one that includes volumes that share a common location, especially if you often move volumes for load-balancing or space reasons. Most often, then, it is appropriate to use the regular expression .* (period followed by a backslash) for the -server and -partition arguments to the backup addvolentry command.
It is generally more efficient to include a limited number of volumes in a volume entry. Dumps of a volume set that includes a large number of volume can take a long time to complete, increasing the possibility that the operation fails due to a service interruption or outage.
To remove a volume entry from a volume set, use the backup delvolentry command. To remove a volume set and all of its component volume entries from the Backup Database, use the backup delvolset command. To display the volume entries in a volume set, use the backup listvolsets command.
By default, a Backup Database record is created for the new volume set. Sometimes it is convenient to create volume sets without recording them permanently in the Backup Database, for example when using the backup volsetrestore command to restore a group of volumes that were not necessarily backed up together (for further discussion, see Using the backup volsetrestore Command). To create a temporary volume set, include the -temporary flag to the backup addvolset command. A temporary volume set exists only during the lifetime of the current interactive session, so the flag is effective only when used during an interactive session (opened by issuing the backup (interactive) command). You can use the backup delvolset command to delete a temporary volume set before the interactive session ends, if you wish, but as noted it is automatically deleted when you end the session. One advantage of temporary volume sets is that the backup addvolset command, and any backup addvolentry commands subsequently used to add volume entries to it, complete more quickly than for regular volume sets, because you are not creating any Backup Database records.
% bos listusers <machine name>
% backup
backup> addvolset <volume set name> [-temporary]
where
% bos listusers <machine name>
% backup
backup> addvolentry -name <volume set name> \
-server <machine name> \
-partition <partition name> \
-volumes <volume name (regular expression)>
where
% backup listvolsets [<volume set name>]
where
The output from the command uses the wildcard notation used when the volume entries were created. The string (temporary) marks a temporary volume set. The following example displays all three of the volume sets defined in a cell's Backup Database, plus a temporary volume set pat+jones created during the current interactive session:
backup> listv
Volume set pat+jones (temporary):
Entry 1: server fs1.abc.com, partition /vicepe, volumes: user.pat.backup
Entry 2: server fs5.abc.com, partition /viceph, volumes: user.jones.backup
Volume set user:
Entry 1: server .*, partition .*, volumes: user.*\.backup
Volume set sun:
Entry 1: server .*, partition .*, volumes: sun4x_55\..*
Entry 2: server .*, partition .*, volumes: sun4x_56\..*
Volume set rs:
Entry 1: server .*, partition .*, volumes: rs_aix42\..*
% bos listusers <machine name>
% backup delvolset <volume set name>+
where
% bos listusers <machine name>
% backup
backup> listvolsets <volume set name>
where
backup> delvolentry <volume set name> <volume entry index>
where
A dump hierarchy is a logical structure in the Backup Database that defines the relationship between full and incremental dumps; that is, it defines which dump serves as the parent for an incremental dump. Each individual component of a hierarchy is a dump level.
As you define dump levels with the backup adddump command, keep the following rules and suggestions in mind:
The following example shows three hierarchies. Each begins with a full dump at the top: sunday1 for the first hierarchy, sunday2 for the second hierarchy, and sunday_bin for the third hierarchy. In all three hierarchies, each of the other dump levels is an incremental level.
/sunday1
/monday
/tuesday
/wednesday
/thursday
/friday
/sunday2
/monday
/tuesday
/wednesday
/thursday
/friday
/sunday_bin
/monday
/wednesday
/friday
In the first hierarchy, each incremental dump level refers to the full level /sunday1 as its parent. When (for example) you dump a volume set at the /sunday1/wednesday level, it includes data that has changed since the volume set was dumped at the /sunday1 level.
In contrast, each incremental dump level in the second hierarchy refers to the immediately preceding dump level as its parent. When you dump a volume set at the corresponding level in the second hierarchy (/sunday2/monday/tuesday/wednesday), the dump includes only data that has changed since the volume set was dumped at the /sunday2/monday/tuesday level (presumably the day before). Assuming you create dumps on the indicated days, an incremental dump made using this hierarchy contains less data than an incremental dump made at the corresponding level in the first hierarchy.
The third hierarchy is more appropriate for dumping volumes for which a daily backup is excessive because the data does not change often (for example, system binaries).
If your cell is like most cells, you have a limited amount of room for storing backup tapes and a limited budget for new tapes. The easiest solution is to recycle tapes by overwriting them when you no longer need the backup data on them. The Backup System helps you implement a recycling schedule by enabling you to associate an expiration date with each dump level. The expiration date defines when a dump created at that level expires. Until that time the Backup System refuses to overwrite a tape that contains the dump. Thus, assigning expiration dates automatically determines how you recycle tapes.
When designing a tape-recycling schedule, you must decide how far in the past and to what level of precision you want to guarantee access to backed up data. For instance, if you decide to guarantee that you can restore a user's home volume to its state on any given day in the last two weeks, you cannot recycle the tape that contains a given daily dump for at least two weeks after you create it. Similarly, if you decide to guarantee that you can restore home volumes to their state at the beginning of any given week in the last month, you cannot recycle the tapes in a dump set containing a weekly dump for at least four weeks. The following example dump hierarchy implements this recycling schedule by setting the expiration date for each daily incremental dump to 13 days and the expiration date of the weekly full dumps to 27 days.
The tapes used to store dumps created at the daily incremental levels in the /sunday1 hierarchy expire just in time to be recycled for daily dumps in the /sunday3 hierarchy (and vice versa), and there is a similar relationship between the /sunday2 and /sunday4 hierarchies. Similarly, the tape that houses a full dump at the /sunday1 level expires just in time to be used for a full dump on the first Sunday of the following month.
/sunday1 expires in 27d
/monday1 expires in 13d
/tuesday1 expires in 13d
/wednesday1 expires in 13d
/thursday1 expires in 13d
/friday1 expires in 13d
/sunday2 expires in 27d
/monday2 expires in 13d
/tuesday2 expires in 13d
/wednesday2 expires in 13d
/thursday2 expires in 13d
/friday2 expires in 13d
/sunday3 expires in 27d
/monday1 expires in 13d
/tuesday1 expires in 13d
/wednesday1 expires in 13d
/thursday1 expires in 13d
/friday1 expires in 13d
/sunday4 expires in 27d
/monday2 expires in 13d
/tuesday2 expires in 13d
/wednesday2 expires in 13d
/thursday2 expires in 13d
/friday2 expires in 13d
If you use appended dumps in your cell, keep in mind that all dumps in a dump set are subject to the latest (furthest into the future) expiration date associated with any of the constituent dumps. You cannot recycle any of the tapes that contain a dump set until all of the dumps have reached their expiration date. See also Appending Dumps to an Existing Dump Set.
Most tape manufacturers recommend that you write to a tape a limited number of times, and it is best not to exceed this limit when recycling tapes. To help you track tape usage, the Backup System records a useCount counter on the tape's label. It increments the counter each time the tape's label is rewritten (each time you use the backup labeltape or backup dump command). To display the useCount counter, use the backup readlabel or backup scantape command or include the -id and -verbose options when you issue the backup dumpinfo command. For instructions see Writing and Reading Tape Labels or Displaying Backup Dump Records.
Even if you make extensive use of tape recycling, there is probably some backup data that you need to archive for a long (or even an indefinite) period of time. You can use the Backup System to archive data on a regular schedule, and you can also choose to archive data on tapes that you previously expected to recycle.
If you want to archive data on a regular basis, you can create date-specific dump levels in the dump hierarchy. For example, if you decide to archive a full dump of all data in your cell at the beginning of each quarter in the year 2000, you can define the following levels in the dump hierarchy:
/1Q2000 /2Q2000 /3Q2000 /4Q2000
If you decide to archive data that is on tapes you previously planned to recycle, you must gather all of the tapes that contain the relevant dumps, both full and incremental. To avoid accidental erasure, it is best to set the switch on the tapes that makes them read-only, before placing them in your archive storage area. If the tapes also contain a large amount of extraneous data that you do not want to archive, you can restore just the relevant data into a new temporary volume, and back up that volume to the smallest number of tapes possible. One reason to keep a dump set small is to minimize the amount of irrelevant data in a dump set you end up needing to archive.
If you do not expect to restore archived data to the file system, you can consider using the backup deletedump command to remove the associated dump records from the Backup Database, which helps keep it to an efficient size. If you ever need to restore the data, you can use the -dbadd flag to the backup scantape command to reinsert the dump records into the database. For instructions, see To scan the contents of a tape.
To associate an expiration date with a dump level as you create it, use the -expires argument to the backup adddump command. To change an existing dump level's expiration date, use the -expires argument to the backup setexp command. (Note that it is not possible to change the expiration date of an actual dump that has already been created at that level). With both commands, you can define an expiration date either in absolute terms (for example, 13 January 2000) or relative terms (for example, 30 days from when the dump is created).
[at] mm/dd/yyyy [hh:MM]
where mm indicates the month, dd the day, and yyyy the year when the dump expires. Valid values for the year fall in the range 1970 through 2037 (the latest possible date that the UNIX time representation can express is in early 2038). If you provide a time, it must be in 24-hour format with hh the hours and MM the minutes (for example, 21:50 is 9:50 p.m.). If you omit the time, the default is 00:00 hours (12:00 midnight) on the indicated date.
[in] [yearsy] [monthsm] [daysd]
where each of years, months, and days is an integer. Provide at least one of them together with the corresponding units letter (y, m, or d respectively), with no intervening space. If you provide more than one of the three, list them in the indicated order.
The Backup System calculates a dump's actual expiration date by adding the indicated relative value to the start time of the dump operation. For example, it assigns an expiration date 1 year, 6 months, and 2 days in the future to a dump created at a dump level with associated expiration date in 1y 6m 2d.
If you omit the -expires argument to the backup adddump command, then the expiration date is set to UNIX time zero (00:00 hours on 1 January 1970). The Backup System considers dumps created at such a dump level to expire at their creation time. If no dumps in a dump set have an expiration date, then the Backup System does not impose any restriction on recycling the tapes that contain the dump set. If you need to prevent premature recycling of the tapes that contain the dump set, you must use a manual tracking system.
% bos listusers <machine name>
% backup
backup> adddump -dump <dump level name>+ [-expires <expiration date>+]
where
Provide the entire pathname of the dump level, preceding each level in the pathname with a slash (/). Each component level can be up to 28 characters in length, and the pathname can include up to 256 characters including the slashes.
| Note: | A plus sign follows this argument in the command's syntax statement because it accepts a multiword value which does not need to be enclosed in double quotes or other delimiters, not because it accepts multiple dates. Provide only one date (and optionally, time) definition to be associated with each dump level specified by the -dump argument. |
% bos listusers <machine name>
% backup
backup> setexp -dump <dump level name>+ [-expires <expiration date>+]
where
| Note: | A plus sign follows this argument in the command's syntax statement because it accepts a multiword value which does not need to be enclosed in double quotes or other delimiters, not because it accepts multiple dates. Provide only one date (and optionally, time) definition to be associated with each dump level specified by the -dump argument. |
% bos listusers <machine name>
% backup
backup> deldump <dump level name>
where
% backup listdumps
where listd is the shortest acceptable abbreviation of listdumps.
The output from this command displays the dump hierarchy, reporting the expiration date associated with each dump level, as in the following example.
% backup listdumps
/week1 expires in 27d
/tuesday expires in 13d
/thursday expires in 13d
/sunday expires in 13d
/tuesday expires in 13d
/thursday expires in 13d
/week3 expires in 27d
/tuesday expires in 13d
/thursday expires in 13d
/sunday expires in 13d
/tuesday expires in 13d
/thursday expires in 13d
sunday1 expires in 27d
/monday1 expires in 13d
/tuesday1 expires in 13d
/wednesday1 expires in 13d
/thursday1 expires in 13d
/friday1 expires in 13d
sunday2 expires in 27d
/monday2 expires in 13d
/tuesday2 expires in 13d
/wednesday2 expires in 13d
/thursday2 expires in 13d
/friday2 expires in 13d
sunday3 expires in 27d
/monday1 expires in 13d
/tuesday1 expires in 13d
/wednesday1 expires in 13d
/thursday1 expires in 13d
/friday1 expires in 13d
sunday4 expires in 27d
/monday2 expires in 13d
/tuesday2 expires in 13d
/wednesday2 expires in 13d
/thursday2 expires in 13d
/friday2 expires in 13d
As described in Dump Names and Tape Names and Tape Labels, Dump Labels, and EOF Markers, you can assign either a permanent name or an AFS tape name to a tape that you use in the Backup System. The names are recorded on the tape's magnetic label, along with an indication of the tape's capacity (size).
You can assign either a permanent name or an AFS tape name, but not both. In general, assigning permanent names rather than AFS tape names simplifies the backup process, because the Backup System does not dictate the format of permanent names. If a tape does not have a permanent name, then by default the Backup System accepts only three strictly defined values in the AFS tape name field, and refuses to write a dump to a tape with an inappropriate AFS tape name. The acceptable values are a name that matches the volume set and dump level of the initial dump, the value <NULL>, and no value in the field at all.
If a tape has a permanent name, the Backup System does not check the AFS tape name, and as part of the dump operation constructs the appropriate AFS tape name itself and records it on the label. This means that if you assign a permanent name, the Backup System assigns an AFS tape name itself and the tape has both types of name. In contrast, if a tape has an AFS tape name but not a permanent name, you cannot assign a permanent name without first erasing the AFS tape name.
(You can also suppress the Backup System's check of a tape's AFS tape name, even it does not have a permanent name, by assigning the value NO to the NAME_CHECK instruction in the device configuration file. See Eliminating the AFS Tape Name Check.)
Because the Backup System accepts unlabeled tapes, you do not have to label a tape before using it for the first time. After the first use, there are a couple of cases in which you must relabel a tape in order to write a dump to it:
| Note: | Labeling a tape that contains dump data makes it impossible to use that data in a restore operation, because the labeling operation removes the dump's records from the Backup Database. If you want to record a permanent name on a tape label, you must do it before dumping any data to the tape. |
To write a permanent name on a tape's label, include the -pname argument to specify a string of up to 32 characters. Check that no other tape used with the Backup System in your cell already has the permanent name you are assigning, because the Backup System does not prevent you from assigning the same name to multiple tapes. The Backup System overwrites the existing AFS tape name, if any, with the value <NULL>. When a tape has a permanent name, the Backup System uses it instead of the AFS tape name in most prompts and when referring to the tape in output from backup commands. The permanent name persists until you again include the -pname argument to the backup labeltape command, regardless of the tape's contents and of how often you recycle the tape or use the backup labeltape command without the -pname argument.
To write an AFS tape name on the label, provide a value for the -name argument that matches the volume set name and the final element in the dump level pathname of the initial dump that you plan to write to the tape, and an index that indicates the tape's place in the sequence of tapes for the dump set. The format is as follows:
volume_set_name.dump_level_name.tape_index
If you omit the -name argument, the Backup System sets the AFS tape name to <NULL>. The Backup System automatically constructs and records the appropriate name when you later write an initial dump to the tape by using the backup dump or backup savedb command.
You cannot use the -name argument if the tape already has a permanent name. To erase a tape's permanent name, provide a null value to the -pname argument by issuing the following command:
% backup labeltape -pname ""
To record the tape's capacity on the label, specify a number of kilobytes as the -size argument. If you omit this argument the first time you label a tape, the Backup System records the default tape capacity associated with the specified port offset in the /usr/afs/backup/tapeconfig file on the Tape Coordinator machine. If the tape's capacity is different (in particular, larger) than the capacity recorded in the tapeconfig file, it is best to record a capacity on the label before using the tape. Once set, the value in the label's capacity field persists until you again use the -size argument to the backup labeltape command. For a discussion of the appropriate capacity to record for tapes, see Configuring the tapeconfig File.
To read a tape's label, use the backup readlabel command.
Most tapes also come with an adhesive label you can apply to the exterior casing. To help you easily identify a tape, record at least the tape's permanent and AFS tape names on the adhesive label. Depending on the recycling scheme you use, it can be useful to record other information, such as the dump ID, dump creation date, and expiration date of each dump you write to the tape.
% bos listusers <machine name>
% butc [<port offset>] [-noautoquery]
% backup
backup> labeltape [-name <tape name, defaults to NULL>] \
[-size <tape size in Kbytes, defaults to size in tapeconfig>] \
[-portoffset <TC port offset>] [-pname <permanent tape name>]
where
volume_set_name.dump_level_name.tape_index
for the tape to be acceptable for use in a future backup dump operation. The volume_set_name must match the volume set name of the initial dump to be written to the tape, dump_level_name must match the last element of the dump level pathname at which the volume set is to be dumped, and tape_index must correctly indicate the tape's place in the sequence of tapes that house the dump set; indexing begins with the number 1 (one).
If you provide a value, it is an integer value followed by a letter that indicates units, with no intervening space. A unit value of k or K indicates kilobytes, m or M indicates megabytes, and g or G indicates gigabytes. If you omit the units letter, the default is kilobytes.
Include this argument or the -name argument, but not both. When you provide this argument, the AFS tape name is set to <NULL>. If you omit this argument, any existing permanent name is retained.
% bos listusers <machine name>
% butc [<port offset>] [-noautoquery]
% backup
backup> readlabel [<TC port offset>]
where
Information from the tape label appears both in the backup command window and in the Tape Coordinator window. The output in the command window has the following format:
Tape read was labelled: tape_name (initial_dump_ID)
size: size KBytes
where tape_name is the tape's permanent name (if it has one) or AFS tape name, initial_dump_ID is the dump ID of the initial dump on the tape, and size is the capacity recorded on the label, in kilobytes.
The information in the Tape Coordinator window is more extensive. The tape's permanent name appears in the tape name field and its AFS tape name in the AFS tape name field. If either name is undefined, a value of <NULL> appears in the field instead. The capacity recorded on the label appears in the size field. Other fields in the output report the creation time, dump level name, and dump ID of the initial dump on the tape (creationTime, dump path, and dump id respectively). The cell field reports the cell in which the dump operation was performed, and the useCount field reports the number of times the tape has been relabeled, either with the backup labeltape command or during a dump operation. For further details, see the command's reference page in the IBM AFS Administration Reference.
If the tape has no label, or if the drive is empty, the following message appears at the command shell:
Failed to read tape label.
The following example illustrates the output in the command shell for a tape in the device with port offset 1:
% backup readlabel 1
Tape read was labelled: monthly_guest (917860000)
size: 2150000 KBytes
The following output appears in the Tape Coordinator window at the same time:
Tape label ---------- tape name = monthly_guest AFS tape name = guests.monthly.3 creationTime = Mon Feb 1 04:06:40 1999 cell = abc.com size = 2150000 Kbytes dump path = /monthly dump id = 917860000 useCount = 44 -- End of tape label --
The Backup System includes several optional features to help you automate the backup process in your cell and make it more efficient. By combining several of the features, you can dump volume data to tape with minimal human intervention in most cases. To take advantage of many of the features, you create a device configuration file in the /usr/afs/backup directory for each tape device that participates in automated operations. For general instructions on creating the device configuration file, see Creating a Device Configuration File. The following list refers you to sections that describe each feature in greater detail.
There are two additional ways to increase backup automation and efficiency that do not involve the device configuration file:
To use many of the features that automate backup operations, create a configuration file for each tape device in the /usr/afs/backup directory on the local disk of the Tape Coordinator machine that drives the device. The filename has the following form:
CFG_device_name
where device_name represents the name of the tape device or backup data file (see Dumping Data to a Backup Data File to learn about writing dumps to a file rather than to tape).
For a tape device, construct the device_name portion of the name by stripping off the initial /dev/ string with which all UNIX device names conventionally begin, and replacing any other slashes in the name with underscores. For example, CFG_rmt_4m is the appropriate filename for a device called /dev/rmt/4m.
For a backup data file, construct the device_name portion by stripping off the initial slash (/) and replacing any other slashes (/) in the name with underscores. For example, CFG_var_tmp_FILE is the appropriate filename for a backup data file called /var/tmp/FILE.
Creating a device configuration file is optional. If you do not want to take advantage of any of the features that the file provides, you do not have to create it.
You can include one of each of the following instructions in any order in a device configuration file. All are optional. Place each instruction on its own line, but do not include any newline (<Return>) characters within an instruction.
A tape stacker or jukebox helps you automate backup operations because it can switch between multiple tapes during an operation without human intervention. To take advantage of this feature, include the MOUNT and optionally UNMOUNT instructions in the device configuration file that you write for the stacker or jukebox. The instructions share the same syntax:
MOUNT filename UNMOUNT filename
where filename is the pathname on the local disk of a script or program you have written that invokes the routines defined by the device's manufacturer for mounting or unmounting a tape in the device's tape drive. (For convenience, the following discussion uses the term script to refers to both scripts and programs.) The script usually also contains additional logic that handles error conditions or modifies the script's behavior depending on which backup operation is being performed.
You can refer to different scripts with the MOUNT or UNMOUNT instructions, or to a single script that invokes both mounting and unmounting routines. The scripts inherit the local identity and AFS tokens associated with to the issuer of the butc command.
You need to include a MOUNT instruction in the device configuration file for all tape devices, but the need for an UNMOUNT instruction depends on the tape-handling routines that the device's manufacturer provides. Some devices, usually stackers, have only a single routine for mounting tapes, which also automatically unmounts a tape whose presence prevents insertion of the required new tape. In this case, an UNMOUNT instruction is not necessary. For devices that have separate mounting and unmounting routines, you must include an UNMOUNT instruction to remove a tape when the Tape Coordinator is finished with it; otherwise, subsequent attempts to run the MOUNT instruction fail with an error.
When the device configuration file includes a MOUNT instruction, you must stock the stacker or jukebox with the necessary tapes before running a backup operation. Many jukeboxes are able to search for the required tape by reading external labels (such as barcodes) on the tapes, but many stackers can only switch between tapes in sequence and sometimes only in one direction. In the latter case, you must also stock the tapes in the correct order.
To obtain a list of the tapes required for a restore operation so that you can prestock them in the tape device, include the -n flag on the appropriate backup command (backup diskrestore, backup volrestore, or backup volsetrestore). For a dump operation, it is generally sufficient to stock the device with more tapes than the operation is likely to require. You can prelabel the tapes with permanent names or AFS tape names, or not prelabel them at all. If you prelabel the tapes for a dump operation with AFS tape names, then it is simplest to load them into the stacker in sequential order by tape index. But it is probably simpler still to prelabel tapes with permanent tape names or use unlabeled tapes, in which case the Backup System generates and applies the appropriately indexed AFS tape name itself during the dump operation.
When you issue the butc command to initialize the Tape Coordinator for a given tape device, the Tape Coordinator looks for the device configuration file called /usr/afs/backup/CFG_device_name on its local disk, where device_name has the format described in Creating a Device Configuration File. If the file exists and contains a MOUNT instruction, then whenever the Tape Coordinator needs a tape, it executes the script named by the instruction's filename argument.
If the device configuration file does not exist, or does not include a MOUNT instruction, then whenever the Tape Coordinator needs a tape, it generates a prompt in its window instructing the operator to insert the necessary tape. The operator must insert the tape and press <Return> before the Tape Coordinator continues the backup operation.
Note, however, that you can modify the Tape Coordinator's behavior with respect to the first tape needed for an operation, by setting the AUTOQUERY instruction in the device configuration file to NO, or including the -noautoquery flag to the butc command. In this case, the Tape Coordinator does not execute the MOUNT instruction or prompt for a tape at the start of an operation, because it expects to find the required first tape in the drive. See Eliminating the Search or Prompt for the Initial Tape.
If there is an UNMOUNT instruction in the device configuration file, then whenever the Tape Coordinator closes the tape device, it executes the script named by the instruction's filename argument. It executes the script only once, and regardless of whether the close operation on the device succeeded or not. If the device configuration file does not include an UNMOUNT instruction, then the Tape Coordinator takes no action.
When the Tape Coordinator executes the MOUNT script, it passes in five parameters, ordered as follows. You can use the parameters in your script to refine its response to varying circumstances that can arise during a backup operation.
Your MOUNT script must return one of the following exit codes to tell the Tape Coordinator whether or not it mounted the tape successfully:
When the Tape Coordinator executes the UNMOUNT script, it passes in two parameters in the following order.
The following example script uses two of the parameters passed to it by the Backup System: tries and operation. It follows the recommended practice of exiting if the value of the tries parameter exceeds one, because that implies that the stacker is out of tapes.
For a backup dump or backup savedb operation, the routine calls the example stackerCmd_NextTape function provided by the stacker's manufacturer. Note that the final lines in the file return the exit code that prompts the operator to insert a tape; these lines are invoked when either the stacker cannot load a tape or a the operation being performed is not one of those explicitly mentioned in the file (is a restore operation, for example).
#! /bin/csh -f
set devicefile = $1
set operation = $2
set tries = $3
set tapename = $4
set tapeid = $5
set exit_continue = 0
set exit_abort = 1
set exit_interactive = 2
#--------------------------------------------
if (${tries} > 1) then
echo "Too many tries"
exit ${exit_interactive}
endif
if (${operation} == "unmount") then
echo "UnMount: Will leave tape in drive"
exit ${exit_continue}
endif
if ((${operation} == "dump") |\
(${operation} == "appenddump") |\
(${operation} == "savedb")) then
stackerCmd_NextTape ${devicefile}
if (${status} != 0)exit${exit_interactive}
echo "Will continue"
exit ${exit_continue}
endif
if ((${operation} == "labeltape") |\
(${operation} == "readlabel")) then
echo "Will continue"
exit ${exit_continue}
endif
echo "Prompt for tape"
exit ${exit_interactive}
By default, the Tape Coordinator obtains the first tape it needs for a backup operation by reading the device configuration file for the appropriate tape device. If there is a MOUNT instruction in the file, the Tape Coordinator executes the referenced script. If the device configuration file does not exist or does not have a MOUNT instruction in it, the Tape Coordinator prompts you to insert the correct tape and press <Return>.
If you know in advance that an operation requires a tape, you can increase efficiency by placing the required tape in the drive before issuing the backup command and telling the Tape Coordinator's to skip its initial tape-acquisition steps. This both enables the operation to begin more quickly and eliminates that need for you to be present to insert a tape.
There are two ways to bypass the Tape Coordinator's initial tape-acquisition steps:
To avoid any error conditions that require operator attention, be sure that the tape you are placing in the drive does not contain any unexpired dumps and is not write protected. If there is no permanent name on the tape's label and you are creating an initial dump, make sure that the AFS tape name either matches the volume set and dump set names or is <NULL>. Alternatively, suppress the Tape Coordinator's name verification step by assigning the value NO to the NAME_CHECK instruction in the device configuration file, as described in Eliminating the AFS Tape Name Check.
By default, the Tape Coordinator asks you how to respond when it encounters certain error conditions. To suppress the prompts and cause the Tape Coordinator to handle the errors in a predetermined manner, include the instruction ASK NO in the device configuration file. If you assign the value YES, or omit the ASK instruction completely, the Tape Coordinator prompts you for direction when it encounters one of the errors.
The following list describes the error conditions and the Tape Coordinator's response to them.
If a tape does not have a permanent name and you are writing an initial dump to it, then by default the Backup System verifies that the tape's AFS tape name is acceptable. It accepts three types of values:
To bypass the name check, include the NAME_CHECK NO instruction in the device configuration file. This enables you to recycle a tape without first relabeling it, as long as all dumps on it are expired. (If a tape has unexpired dumps on it but you want to recycle it anyway, you must use the backup labeltape command to relabel it first. For this to work, the ASK NO instruction cannot appear in the device configuration file.)
By default, the Tape Coordinator uses a 16-KB memory buffer during dump operations. As it receives volume data from the Volume Server, the Tape Coordinator gathers 16 KB of data in the buffer before transferring the entire 16 KB to the tape device. Similarly, during a restore operation the Tape Coordinator by default buffers 32 KB of data from the tape device before transferring the entire 32 KB to the Volume Server for restoration into the file system. Buffering makes the volume of data flowing to and from a tape device more even and so promotes tape streaming, which is the most efficient way for a tape device to operate.
In a normal network configuration, the default buffer sizes are usually large enough to promote tape streaming. If the network between the Tape Coordinator machine and file server machines is slow, it can help to increase the buffer size.
To determine if altering the buffer size is helpful for your configuration, observe the tape device in operation to see if it is streaming, or consult the manufacturer. To set the buffer size, include the BUFFERSIZE instruction in the device configuration file. It takes an integer value, and optionally units, in the following format:
BUFFERSIZE size[{k | K | m | M | g | G}]
where size specifies the amount of memory the Tape Coordinator allocates to use as a buffer during both dump and restore operations. The default unit is bytes, but use k or K to specify kilobytes, m or M for megabytes, and g or G for gigabytes. There is no space between the size value and the units letter.
You can write dumps to a backup data file rather than to tape. This is useful if, for example, you want to transfer the data to a data-archiving system, such as a hierarchical storage management (HSM) system, that you use in conjunction with AFS and the Backup System. You can restore data from a backup data file into the file system as well. Using a backup data file is usually more efficient than issuing the equivalent vos dump and vos restore commands individually for multiple volumes.
Writing to a backup data file is simplest if it is on the local disk of the Tape Coordinator machine, but you can also write the file to an NFS-mounted partition that resides on a remote machine. It is even acceptable to write to a file in AFS, provided that the access control list (ACL) on its parent directory grants the necessary permissions, but it is somewhat circular to back up AFS data into AFS itself.
If the backup data file does not already exist when the Tape Coordinator attempts to write a dump to it, the Tape Coordinator creates it. For a restore operation to succeed, the file must exist and contain volume data previously written to it during a backup dump operation.
When writing to a backup data file, the Tape Coordinator writes data at 16 KB offsets. If a given block of data (such as the marker that signals the beginning or end of a volume) does not fill the entire 16 KB, the Tape Coordinator still skips to the next offset before writing the next block. In the output of a backup dumpinfo command issued with the -id option, the value in the Pos column is the ordinal of the 16-KB offset at which the volume data begins, and so is not generally only one higher than the position number on the previous line, as it is for dumps to tape.
Before writing to a backup data file, you need to configure the file as though it were a tape device.
| Note: | A file pathname, rather than a tape device name, must appear in the third field of the /usr/afs/backup/tapeconfig file when the FILE YES instruction appears in the device configuration file, and vice versa. If the tapeconfig file instead refers to a tape device, dump operations appear to succeed but are inoperative. You cannot restore data that you accidently dumped to a tape device while the FILE instruction was set to YES. In the same way, if the FILE instruction is set to NO, the tapeconfig entry must refer to an actual tape device. |
% bos listusers <machine name>
% su root Password: root_password
# backup
backup> listhosts
As for a tape device, acceptable values are the integers 0 (zero) through 58510 (the Backup System can track a maximum of 58,511 port offset numbers). Each port offset must be unique in the cell, but you can associate any number them with a single Tape Coordinator machine. You do not have to assign port offset numbers sequentially.
backup> addhost <tape machine name> [<TC port offset>]
where
[capacity filemark_size] device_name port_offset
where
Specify a numerical value followed by a letter that indicates units, with no intervening space. The letter k or K indicates kilobytes, m or M indicates megabytes, and g or G indicates gigabytes. If you omit the units letter, the default is kilobytes. If you leave this field empty, the Tape Coordinator uses the maximum acceptable value (2048 GB or 2 TB). Also leave the filemark_size field empty in that case.
If this field names the actual file, there is no way to recover from exhausting the space on the partition. You cannot change the tapeconfig file in the middle of an operation.
Construct the device_name portion of the name based on the device name you recorded in the tapeconfig file in Step 6. If, as recommended, you recorded a symbolic link name, strip off the /dev/ string and replace any other slashes (/) in the name with underscores (_). For example, CFG_FILE is the appropriate name if the symbolic link is /dev/FILE. If you recorded the name of an actual file, then strip off the initial slash only and replace any other slashes in the name with underscores. For a backup data file called /var/tmp/FILE, the appropriate device configuration filename is CFG_var_tmp_FILE.
You do not need to create the backup data file itself, because the Tape Coordinator does so if the file does not exist when the dump operation begins.
The following example script illustrates how you can automatically create a symbolic link to the backup data file during the preparation phase for writing to the file. When the Tape Coordinator is executing a backup dump, backup restore, backup savedb, or backup restoredb operation, the routine invokes the UNIX ln -s command to create a symbolic link from the backup data file named in the tapeconfig file to the actual file to use (this is the recommended method). It uses the values of the tapename and tapeid parameters passed to it by the Backup System when constructing the filename.
The routine makes use of two other parameters as well: tries and operation. The tries parameter tracks how many times the Tape Coordinator has attempted to access the file. A value greater than one indicates that the Tape Coordinator cannot access it, and the routine returns exit code 2 (exit_interactive), which results in a prompt for the operator to load a tape. The operator can use this opportunity to change the name of the backup data file specified in the tapeconfig file.
#! /bin/csh -f
set devicefile = $1
set operation = $2
set tries = $3
set tapename = $4
set tapeid = $5
set exit_continue = 0
set exit_abort = 1
set exit_interactive = 2
#--------------------------------------------
if (${tries} > 1) then
echo "Too many tries"
exit ${exit_interactive}
endif
if (${operation} == "labeltape") then
echo "Won't label a tape/file"
exit ${exit_abort}
endif
if ((${operation} == "dump") |\
(${operation} == "appenddump") |\
(${operation} == "restore") |\
(${operation} == "savedb") |\
(${operation} == "restoredb")) then
/bin/rm -f ${devicefile}
/bin/ln -s /hsm/${tapename}_${tapeid} ${devicefile}
if (${status} != 0) exit ${exit_abort}
endif
exit ${exit_continue}
![[Top of Topic]](../top.gif)