Tivoli Storage Manager for Windows: Administrator's Guide


Configuring Policy for Specific Cases

This section includes recommendations for some cases for which policy changes may be needed.

Configuring Policy for Direct-to-Tape Backups

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 in order 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. On the other hand, 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:

  1. Double-click the desktop icon for the TSM Console.
  2. Expand the tree until the TSM server you want to work with is displayed. Expand the server and click Wizards. The Wizards list appears in the right pane.
  3. Select the Client Node Configuration wizard and click Start. The Client Node Configuration Wizard appears.
  4. Progress through the wizard to the Define TSM client nodes and policy panel.
  5. Drag the clients from the client node list on the right and drop them on a tape storage pool.
  6. Finish the wizard.

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:

  1. Copy the default policy domain STANDARD as a template:
    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.

  2. Update the backup or archive copy group in the DIR2TAPE policy domain to specify the destination to be a tape storage pool. For example, to use a tape storage pool named TAPEPOOL for backup, enter the following command:
    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
    
  3. Activate the changed policy set.
    activate policyset dir2tape standard
    
  4. Assign client nodes to the DIR2TAPE policy domain. For example, to assign a client node named TAPEUSER1 to the DIR2TAPE policy domain, enter the following command:
    update node tapeuser1 domain=dir2tape
    

Configuring Policy for Tivoli Data Protection Application Clients

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.

Policy for Logical Volume Backups

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 18 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 18. 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

|Configuring Policy for Tivoli Data Protection for NDMP

| |

|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 5, 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 Using the |Backup-Archive Client for your particular client platform. For |more information about client option sets see Creating Client Option Sets from the Server.

Configuring Policy for Managed System for SAN

With the Managed System for SAN feature, you can set up a SAN configuration in which a TSM 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 TSM Clients to Directly Access SAN-Attached Devices 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:

Define a New 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:

  1. Create the policy domain for the clients. For example, to define a policy domain that is named SANCLIENTS, enter the following command:
    define domain sanclients
     description='Policy domain for clients using SAN devices'
    
  2. Create a policy set in that domain. For example, to define the policy set that is named BASE in the SANCLIENTS policy domain, enter the following command:
    define policyset sanclients base
    
  3. Create the default management class for the policy set. First define the management class, then assign the management class as the default for the policy set.

    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
    
  4. Define the backup copy group in the default management class, as follows: For example, to define the backup copy group for the SANCLIENTMC management class, enter the following command:
    define copygroup sanclients base sanclientmc standard destination=sanpool
    
  5. Define the archive copy group in the default management class, as follows: For example, to define the archive copy group for the SANCLIENTMC management class, enter the following command:
    define copygroup sanclients base sanclientmc standard
     type=archive destination=sanpool
    
  6. Activate the policy set.

    For example, to activate the BASE policy set in the SANCLIENTS policy domain, enter the following command:

    activate policyset sanclients base
    
  7. Register or update the application clients to associate them with the new policy domain.

    For example, to update the node SANCLIENT1, enter the following command:

    update node sanclient1 domain=sanclients
    

Define a New Management Class in an Existing Policy Domain

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 Tivoli Storage Manager Installing the Clients.

Policy for Tivoli Storage Manager Servers as Clients

One TSM server (a source server) can be registered as a client to another TSM 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.

Setting Policy to Enable Point-in-Time Restore for Clients

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 TSM 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.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]