Transarc's AFS backup commands back up AFS volumes to tape devices using the BackUp Tape Coordinator (butc) program. The butc program then prompts for the tapes to which it writes the backup data. Each machine running butc is connected to a tape device that can be a simple drive or a stacker. This AFS volume backup system consists of the following commands:
The TSM agent program, BackUp To TSM (buta), is a replacement for butc, the tape interface program of the volume backup system. The AFS buta program is an interface between the AFS backup commands and a TSM server, and lets you back up and restore AFS data by volume. AFS buta accomplishes these tasks using TSM application program interface (API) function calls. Through the TSM API, each full or incremental volume dump is sent to a TSM server as a file with the same name as the volume.
The volume dump files are stored within a single file space in TSM storage named with the dump ID string. A TSM administrator can delete an AFS backup dump from TSM storage by deleting the file space in which it is stored. When an AFS backup dump is deleted from TSM storage, it is also be removed from the AFS backup database using the AFS backup command. TSM provides a utility program with buta, called delbuta, that performs both of these tasks for you by deleting the unwanted old dumps from both the AFS backup database and the TSM server simultaneously.
To improve the performance of backup operations, start multiple instances of buta at one time, running on the same machine and on different machines.
If you have a small cell and a busy network between file servers and the TSM server, and your TSM server is on AIX, you might want to run only one buta instance on the TSM server to back up all volumes. You can also run one buta instance on each file server machine sequentially, permitting only one buta instance at a time to back up its local volumes to TSM.
If you have a large cell and a dedicated network between file servers and the TSM server, you might want to run one buta instance on every file server, backing up its local volumes so that you can finish the full dumps within the time window available. A large number of buta dumps can be performed simultaneously. The ideal number of concurrent dumps depends on the configurations of your network and servers.
Important: | All instances of buta running on one or more machines must use the same TSM node name and password. |
Note: | System administrators should familiarize themselves with the AFS volume backup system (backup and buserver commands) since the buta program is used as a part of that system and it works like a special version of butc. Refer to the chapters on backup system commands in the AFS manuals. |
Before you start the AFS buta program, you need to define environment variables, install the API, and perform administration tasks. The next sections describe these procedures.
Install the TSM API and the buta program on selected machines.
Note: | The selected machines must also have the AFS Client installed. This then becomes a buta machine. For install procedures, see Tivoli Storage Manager Installing the Clients, SH26-4102. |
Follow the steps below to define TSM environment variables and options.
Note: | The default paths for dsmi_config and dsmi_dir are different for different versions of the TSM API. See the Readme file for the API version you are using to determine the default locations. |
Each buta instance creates a separate log file. If you want the summary of all dumps and restore operations from all buta instances in one file, then you can use the centrallog option to point to that file. You can specify a JFS file if all your buta instances are running on the same machine. If your buta instances are running on different machines and you want the summary from all machines in one file, then you must specify an NFS file with the centrallog option.
Table 8. How to Specify the Options Files
Variable | What it does | Example | ||
---|---|---|---|---|
dsmi_config | Points to the client user options file (dsm.opt). |
export dsmi_config=/usr/afs/buta/dsm.opt | ||
dsmi_dir | Points to the directory that contains the client system options file (dsm.sys). |
export dsmi_dir=/usr/afs/buta | ||
dsmi_log | Points to the directory that contains the API error log file (dsierror.log). |
export dsmi_log=/usr/afs/buta | ||
centrallog | Points to a JFS or NFS central log file where a summary line is logged for each dump or restore from all buta instances. |
export centrallog=/usr/afs/buta/butalogs | ||
delbuta_config | Points to the delbuta options file (delbuta.opt). |
export delbuta_config=/usr/afs/buta/delbuta.opt | ||
|
servername seaside tapeprompt no compressalways yes
servername seaside tcpport 1500 tcpserveraddress seaside.almaden.ibm.com passwordaccess prompt compression yes
/usr/afs/buta/en_US -> /usr/lpp/adsm/bin/en_US
Follow the steps below to add the buta host to the coordinator host database.
backup> addhost <machine name> <port offset>
The machine name parameter is the same as the buta machine name, and the port offset parameter is the same as the port offset you specify to start buta.
Follow these steps to perform TSM administration tasks:
register node <node name> <passwd> backdelete=yes
Note: | Register only one buta node name for all buta instances. The same node name and password should be used for all instances of buta. The node name you select should be different from any of your machine names. |
A backup copy group contains an attribute specifying the destination for your AFS backup dumps. If you want your AFS backup dumps stored in a storage pool separate from other types of backups, your TSM administrator must define a backup copy group specifying that storage pool in the active policy set of the policy domain to which your buta node is assigned.
To start the buta program on a buta machine, do the following:
Another program named buta.afs34a.patch works with the AFS 3.4a patch version (AFS 3.4 revision 4.40 and after) backup and buserver commands.
buta -port <port offset> -node <node name> -password <node password> \ -server <server name>
Where the node name and password are the node name and its password that were registered with a TSM server in "TSM Administration". The server name is the server stanza name from the dsm.sys file rather than a network host name.
You can now use AFS backup commands as usual, specifying a port offset number you defined for each buta command that you enter.
The following AFS backup commands are NOT SUPPORTED by buta:
Note: | For instructions on how to install TSM programs, update options files, and register a client node, see Tivoli Storage Manager Installing the Clients, SH26-4102. |
The buta command starts a buta process on a buta machine.
Enter the buta command over a connection to a buta machine. You must open a separate connection for each buta instance.
If you run buta in the foreground, the connection on which you enter the command is not available for subsequent commands. The buta program uses the connection as a dedicated monitoring connection/window on which to display trace information or prompts. The monitoring connection/window must remain open as long as buta is running. To stop buta, enter an interrupt signal, such as Ctrl-C, in the monitoring window.
If you run buta in the background, use the -alwaysomit parameter to prevent prompting for options if a volume fails to dump.
The buta command writes output to the following two files on the local disk of the buta machine:
The buta command appends information to the log file each time you enter the command. It also appends information to the error log file whenever it encounters a problem. Check the log files periodically to be sure dumps and restores are completing successfully.
Optionally, buta appends summary information to a centrally located log file each time you enter a backup dump or restore command. The buta command appends the summary log to the file pointed to by the centrallog option.
Syntax
>>-buta---+---------------------+---+---------------------+-----> '- -port port offset--' '- -debuglevel level--' >-----+-------------------+---+--------------+------------------> '- -cell cell name--' '- -localauth--' >----- -node node name---+- -password password-------+----------> '- -pipe password file name-' >-----+-----------------------+---------------------------------> '- -server server name--' >-----+------------------------------------+--------------------> '- -mgmtclass management class name--' >-----+---------------------------+---+-----------+-------------> '- -buffersize buffer size--' '- -nodots--' >-----+------------------------------+---+---------------+------> '- -maxpass number of retries--' '- -alwaysomit--' >-----+------------+---+-------------+---+---------+----------->< '- -lastlog--' '- -group id--' '- -help--'
Note: | The -node option, and either the -password or -pipe-option, are required. |
Parameters
A port offset number is a unique number assigned to a buta instance. When entering an AFS backup command, specify the port offset number of the buta instance that is to execute the command. The default is 0. Valid values are 0 through 58510. You can assign the port offset numbers in sequence, or you can skip numbers.
This parameter is required for all buta command invocations if you use multiple TSM servers for buta backup. If you do not use this command parameter, you might not be able to restore the backups properly.
It is recommended that you always use this parameter even if you are not using multiple TSM servers. This prevents you from encountering any restore problems if you later decide to use multiple TSM servers.
Examples
Table 9. Examples of Tasks and Commands
Task | Command |
---|---|
Start an instance of buta at port offset 99. | buta -port 99 -node afsback -password secret1 |
Start an instance of buta at port offset 0 and send the backup dump to a server named jaguar. | buta -node afsback -password secret1 -server jaguar |
An AFS backup dump can be deleted from TSM storage by deleting the file space in which it is stored. A TSM administrator with the appropriate authority can delete a file space from within a TSM administrative client session.
When an AFS backup dump is deleted from TSM storage, it should also be deleted from the AFS backup database. An AFS administrator can delete a backup dump from the AFS backup database using an AFS backup command.
To delete an AFS backup dump from both TSM storage and the AFS backup database, the delbuta command is used. To use this command, you must have the appropriate authority to delete file spaces from TSM storage, and you must hold AFS administrative tokens.
Before you use the delbuta command, update the delbuta.opt file. This file is installed in the same directory as that of the buta program. Both the AFS back up commands and the TSM administrative client must be available on the same machine.