![]() |
![]() |
This section includes recommendations for some cases for which policy changes may be needed.
The server default policy enables client nodes to back up data to disk storage pools on the server. As an alternative, you may configure a policy to store client data directly in tape storage pools to reduce contention for disk resources. If you back up directly to tape, the number of clients that can back up data at the same time is equal to the number of drives available to the storage pool (through the mount limit of the device class). For example, if you have one drive, only one client at a time can back up data.
The direct-to-tape backup eliminates the need to migrate data from disk to tape. However, performance of tape drives is often lower when backing up directly to tape than when backing up to disk and then migrating to tape. Backing up data directly to tape usually means more starting and stopping of the tape drive. Backing up to disk then migrating to tape usually means the tape drive moves more continuously, meaning better performance.
You may complete this task by using the Client Node Configuration Wizard in the TSM Console, or by using the server command line. To use the TSM Console, do the following:
At the server command line, you may define a new policy domain that enables client nodes to back up or archive data directly to tape storage pools. For example, you may define a policy domain named DIR2TAPE with the following steps:
copy domain standard dir2tape
This command creates the DIR2TAPE policy domain that contains a default policy set, management class, backup and archive copy group, each named STANDARD.
update copygroup dir2tape standard standard destination=tapepool
To use a tape storage pool named TAPEPOOL for archive, enter the following command:
update copygroup dir2tape standard standard type=archive destination=tapepool
activate policyset dir2tape standard
update node tapeuser1 domain=dir2tape
The Tivoli Data Protection application clients using the server to store data may require that you configure policy to make the most efficient use of server storage. See the user's guide for each application client for policy requirements.
Some of the application clients include a time stamp in each database backup. Because the default policy for the server keeps one backup version of each unique file, database backups managed by default policy are never deleted because each backup is uniquely named with its time stamp. To ensure that the server deletes backups as required, configure policy as recommended in the user's guide for the application client.
Consider defining a management class specifically for logical volume backups. To enable clients to restore a logical volume and then reconcile the results of any file backup operations since the logical volume backup was made, you must set up management classes with the backup copy group set up differently from the STANDARD. The Versions Data Exists, Versions Data Deleted, and Retain Extra Versions parameters work together to determine over what time period a client can restore a logical volume image and reconcile later file backups. Also, you may have server storage constraints that require you to control the number of backup versions allowed for logical volumes.
Backups of logical volumes are intended to help speed the restoration of a machine. One way to use the capability is to have users periodically (for example, once a month) perform a logical volume backup, and schedule daily full incremental backups. If a user restores a logical volume, the program first restores the logical volume backup and then any files that were changed since the backup (incremental or other file backup processes). The user can also specify that the restore process reconcile any discrepancies that can result when files are deleted.
For example, a user backs up a logical volume, and the following week deletes one or more files from the volume. At the next incremental backup, the server records in its database that the files were deleted from the client. When the user restores the logical volume, the program can recognize that files have been deleted since the backup was created. The program can delete the files as part of the restore process. To ensure that users can use the capability to reconcile later incremental backups with a restored logical volume, you need to ensure that you coordinate policy for incremental backups with policy for backups for logical volumes.
For example, you decide to ensure that clients can choose to restore files and logical volumes from any time in the previous 60 days. You can create two management classes, one for files and one for logical volumes. Table 26 shows the relevant parameters. In the backup copy group of both management classes, set the Retain Extra Versions parameter to 60 days.
In the management class for files, set the parameters so that the server keeps versions based on age rather than how many versions exist. More than one backup version of a file may be stored per day if clients perform selective backups or if clients perform incremental backups more than once a day. The Versions Data Exists parameter and the Versions Data Deleted parameter control how many of these versions are kept by the server. To ensure that any number of backup versions are kept for the required 60 days, set both the Versions Data Exists parameter and the Versions Data Deleted parameter to NOLIMIT for the management class for files. This means that the server retains backup versions based on how old the versions are, instead of how many backup versions of the same file exist.
For logical volume backups, the server ignores the frequency attribute in
the backup copy group.
Table 26. Example of Backup Policy for Files and Logical Volumes
Parameter (backup copy group in the management class) | Management Class for Files | Management Class for Logical Volumes |
---|---|---|
Versions Data Exists | NOLIMIT | 3 versions |
Versions Data Deleted | NOLIMIT | 1 |
Retain Extra Versions | 60 days | 60 days |
Retain Only Version | 120 days | 120 days |
With the Tivoli Data Protection for NDMP product, you can register a NAS file server as a node. Under the direction of the Tivoli Storage Manager server, the NAS file server performs backup and restore of file system images to a tape library. The TSM server initiates the backup, allocates a drive, and selects and mounts the media. The NAS file server then transfers the data to tape.
Because the NAS file server performs the backup, the data is stored in its own format. For Network Appliance file servers, the data is stored in the NETAPPDUMP data format. To manage NAS file server image backups, copy groups for NAS nodes must point to a storage pool that has a data format of NETAPPDUMP. To set up the required policy for NAS nodes, you can define a new, separate policy domain. See Chapter 6, Setting Up Tivoli Data Protection for NDMP for details. The following backup copy group attributes are ignored for NAS images:
Backups for NAS nodes can be initiated from the server, or from a client that has authority over the NAS node. For client-initiated backups, you can use client option sets that contain include and exclude statements to bind NAS file system images to a specific management class. The valid options that can be used for a NAS node are: include.fs.nas, exclude.fs.nas, and domain.nas. For details on the options see the Backup-Archive Installation and User's Guide for your particular client platform. For more information about client option sets see Creating Client Option Sets from the Server.
With the Managed System for SAN feature, you can set up a SAN configuration in which a client directly accesses a storage device to read or write data. SAN data transfer requires setup on the server and on the client, and the installation of a storage agent on the client machine. The storage agent transfers data between the client and the storage device. See TSM Managed System for SAN Storage Agent User's Guide for details. See the Web site for details on clients that support the feature: http://www.tivoli.com/support/storage_mgr/tivolimain.html.
One task in configuring your systems to use this feature is to set up policy for the clients. Copy groups for these clients must point to the storage pool that is associated with the SAN devices. (Configuring Tivoli Storage Manager for LAN-free Data Movement describes how to configure the devices and define the storage pool.) Clients for which you have mapped the SAN drives in this storage pool can then use the SAN to send data directly to the device for backup, archive, restore, and retrieve.
To set up the required policy, either define a new, separate policy domain, or define a new management class in an existing policy domain:
One way to configure policy for clients is to define a separate policy domain in which the active policy set has a default management class with the required settings. Then register all clients using SAN data transfer to that domain. Do the following:
define domain sanclients description='Policy domain for clients using SAN devices'
define policyset sanclients base
For example, to define the management class that is named SANCLIENTMC, enter the following command:
define mgmtclass sanclients base sanclientmc
Then assign the new management class as the default:
assign defmgmtclass sanclients base sanclientmc
The storage pool must already be set up. The storage pool must point to a device class that is associated with the library for the SAN devices. See Configuring Tivoli Storage Manager for LAN-free Data Movement for details.
define copygroup sanclients base sanclientmc standard destination=sanpool
The storage pool must already be set up. The storage pool must point to a device class that is associated with the library for the SAN devices. See Configuring Tivoli Storage Manager for LAN-free Data Movement for details.
define copygroup sanclients base sanclientmc standard type=archive destination=sanpool
For example, to activate the BASE policy set in the SANCLIENTS policy domain, enter the following command:
activate policyset sanclients base
For example, to update the node SANCLIENT1, enter the following command:
update node sanclient1 domain=sanclients
If you choose not to define a separate policy domain with the appropriate management class as the default, you must define a new management class within an existing policy domain and activate the policy set. Because the new management class is not the default for the policy domain, you must add an include statement to each client options file to bind objects to that management class.
For example, suppose sanclientmc is the name of the management class that you defined for clients that are using devices on a SAN. You want the client to be able to use the SAN for backing up any file on the c drive. Put the following line at the end of the client's include-exclude list:
include c:* sanclientmc
For details on the include-exclude list, see Backup-Archive Installation and User's Guide.
One server (a source server) can be registered as a client to another server (the target server). Data stored by the source server appears as archived files on the target server. The source server is registered to a policy domain on the target server, and uses the default management class for that policy domain. In the default management class, the destination for the archive copy group determines where the target server stores data for the source server. Other policy specifications, such as how long to retain the data, do not apply to data stored for a source server. See Using Virtual Volumes to Store Data on Another Server for more information.
To enable clients to restore backed-up files to a specific point in time, you must set up the backup copy group differently from the STANDARD. The Versions Data Exists, Versions Data Deleted, and Retain Extra Versions parameters work together to determine over what time period a client can perform a point-in-time restore operation.
For example, you decide to ensure that clients can choose to restore files from anytime in the previous 60 days. In the backup copy group, set the Retain Extra Versions parameter to 60 days. More than one backup version of a file may be stored per day if clients perform selective backups or if clients perform incremental backups more than once a day. The Versions Data Exists parameter and the Versions Data Deleted parameter control how many of these versions are kept by the server. To ensure that any number of backup versions are kept for the required 60 days, set both the Versions Data Exists parameter and the Versions Data Deleted parameter to NOLIMIT. This means that the server essentially determines the backup versions to keep based on how old the versions are, instead of how many backup versions of the same file exist.
Keeping backed-up versions of files long enough to allow clients to restore their data to a point in time can mean increased resource costs. Requirements for server storage increase because more file versions are kept, and the size of the server database increases to track all of the file versions. Because of these increased costs, you may want to choose carefully which clients can use the policy that allows for point-in-time restore operations.
Clients need to run full incremental backup operations frequently enough so that Tivoli Storage Manager can detect files that have been deleted on the client file system. Only a full incremental backup can detect whether files have been deleted since the last backup. If full incremental backup is not done often enough, clients who restore to a specific time may find that many files that had actually been deleted from the workstation get restored. As a result, a client's file system may run out of space during a restore process.