Chapter 13.

Managing Data for Client Nodes

This chapter contains information to help you generate backup sets and enable subfile backups for client nodes. You can also use data validation for client nodes so that any data corruption is identified when data is sent over the network between the client and server. See the following sections for more information:
Tasks: "Validating a Node's Data During a Client Session" "Generating Client Backup Sets on the Server" Restoring Backup Sets from a Backup-Archive Client "Moving Backup Sets to Other Servers" "Managing Client Backup Sets" "Enabling Clients to Use Subfile Backup" Concepts: Choosing Where to Enable Data Validation Performance Considerations "Creating and Using Client Backup Sets"

Validating a Node's Data

Data validation can identify data corruption during a client session when data is sent between a client and the server. Tivoli Storage Manager provides the option of specifying whether a cyclic redundancy check (CRC) is performed during a client session to validate data sent over the network between a client or a storage agent and the server. Cyclic redundancy checking is performed at the client when the client requests services from the server. For example, the client issues a query, backup, or archive request. The server also performs a CRC operation on the data sent by the client and compares its value with the value calculated by the client. If the CRC values do not match, the server will issue an error message once per session. Depending on the operation, the client may attempt to automatically retry the operation. After Tivoli Storage Manager completes the data validation, the client and server discard the CRC values generated in the current session. Data validation can be enabled for one or all of the following: Tivoli Storage Manager client nodes at Version 5.1. Tivoli Storage Manager storage agents at Version 5.1. For details refer to the storage agent user's guide for your particular operating system.

This section provides information about data validation between a node and the server. See Choosing Where to Enable Data Validation to help you determine where to enable data validation.

Performance Considerations
Consider the impact on performance when you decide whether data validation is necessary for all nodes or some nodes. Data validation impacts performance because additional CPU overhead is required on both the client and server to calculate and compare CRC values. This type of validation is independent from validating data written to a storage pool volume. See Data Validation During Audit Volume Processing.

Validating a Node's Data During a Client Session

You can enable data validation for a node by using the REGISTER NODE or UPDATE NODE command. By default, data validation is set to NO. Methods for enabling data validation for a node include choosing data validation for individual nodes, specifying a set of nodes by using a wildcard search string, or specifying a group of nodes in a policy domain. For example, to enable data validation for existing node, ED, you can issue an UPDATE NODE command. This user backs up the company payroll records weekly and you have decided it is necessary to have all the user data validated: the data itself and metadata. update node ed validateprotocol=all Later, the network has shown to be stable and no data corruption has been identified when user ED has processed backups. You can then disable data validation to minimize the performance impact of validating all of ED's data during a client session. For example: update node ed validateprotocol=no

Creating and Using Client Backup Sets

A backup set is a collection of backed-up data from one client, stored and managed as a single object on specific media in server storage. The server creates copies of active versions of a client's backed up objects that are within the one or more file spaces specified with the GENERATE BACKUPSET command, and consolidates them onto sequential media. Currently, the backup object types supported for backup sets include directories and files only. The process is also called instant archive. The media may be directly readable by a device such as a CD-ROM, JAZ, or ZIP drive attached to a client's machine. Administrators can generate multiple copies of backup sets that correspond to some point-in-time. The backup sets can be retained for various time periods. This is an efficient way to create long-term storage of periodic backups, without requiring the data to be sent over the network again. While an administrator can generate a backup set from any client's backed up files, backup sets can only be used by a backup-archive client. You cannot generate a backup set for a NAS node. See the following sections for details:

Generating Client Backup Sets on the Server Restoring Backup Sets from a Backup-Archive Client Moving Backup Sets to Other Servers Managing Client Backup Sets

Generating Client Backup Sets on the Server

Task Generate a backup set Required Privilege Class System or restricted policy over the domain to which the node is assigned

You can generate backup sets on the server for client nodes. The client node for which a backup set is generated must be registered to the server. An incremental backup must be completed for a client node before the server can generate a backup set for the client node. The GENERATE BACKUPSET command runs as a background process on the server. If you cancel the background process created by this command, the media may not contain a complete backup set. See the following sections: Choosing Media for Generating the Backup Set Selecting a Name for the Backup Set Setting a Retention Period for the Backup Set Example: Generating a Client Backup Set

Choosing Media for Generating the Backup Set

To generate a backup set, you must specify a device class that is associated with the media to which the backup set will be written. Consider the following when you select a device class for writing the backup set: Generate the backup set on any sequential access devices whose device types are supported on both the client and server machines. If you do not have access to compatible devices, you will need to define a device class for a device type that is supported on both the client and server. Ensure that the media type and recording format used for generating the backup set is supported by the device that will be reading the backup set.

You can write backup sets to sequential media: sequential tape and device class FILE. The tape volumes containing the backup set are not associated with storage pools and, therefore, are not migrated through the storage pool hierarchy. For device class FILE, the server creates each backup set with a file extension of OST. You can copy FILE device class volumes to removable media that is associated with CD-ROM, JAZ, or ZIP devices, by using the REMOVABLEFILE device type. For more information, see Configuring Removable File Devices.

Using Scratch Media

You can determine whether to use scratch volumes when you generate a backup set. If you do not use specific volumes, the server uses scratch volumes for the backup set.

You can use specific volumes for the backup set. If there is not enough space to store the backup set on the volumes, the server uses scratch volumes to store the remainder of the backup set.

Selecting a Name for the Backup Set

The server adds a unique suffix to the name you specify for the backup set. For example, if you name the backup set mybackupset, the server adds a unique extension, such as 3099, to the name. This allows you to create backup sets with the same name without overwriting previous backup sets. To later display information about this backup set, you can include a wildcard character with the name, such as mybackupset*, or you can specify the fully qualified name, such as mybackupset.3099.

Setting a Retention Period for the Backup Set

You can set the retention period, specified as a number of days, to retain the backup set on the server. You can specify a number between zero and 9999 days. Backup sets are retained on the server for 365 days if you do not specify a value. The server uses the retention period to determine when to expire the volumes on which the backup set resides.

Example: Generating a Client Backup Set

Generate a backup set on portable media that the client can later use to restore the data. Use the following steps to generate a backup set on a CD-ROM: 1. Define a library whose type is MANUAL. Name the library MANUALLIB. 2. define library manuallib libtype=manual 3. 4. Define a device class whose device type is REMOVABLEFILE. Name the device class BACKSET: 5. define devclass backset devtype=removablefile library=manuallib 6. 7. Define a drive to associate with the library. Name the drive CDDRIVE and the device /cdrom 8. define drive manuallib cddrive device=/cdrom 9. 10. Define a device class whose device type is FILE. Name the device class FILES: 11. define devclass files devtype=file maxcapacity=640M dir=/backupset 12. 13. Generate the backup set to the FILE device class for client node JOHNSON. Name the backup set PROJECT and retain it for 90 days. 14. generate backupset johnson project devclass=file scratch=yes 15. retention=90 16. 17. Use your own software for writing CD-ROMs. For this example, the CD-ROM volume names are VOL1, VOL2, and VOL3. These names were put on the CD-ROM as they were created. For an example of using the backup set on the CD-ROM, see Moving Backup Sets to Other Servers.

Restoring Backup Sets from a Backup-Archive Client

Backup-archive client nodes can restore their backup sets in either of two ways:

Directly from the server. Using a device attached to the client's machine that will read the media in which the backup set is stored.

Backup sets can only be used by a backup-archive client, and only if the files in the backup set originated from a backup-archive client. For more information about restoring backup sets, see Using the Backup-Archive Client guide for your particular operating system.

Moving Backup Sets to Other Servers

Task Define a backup set Required Privilege Class If the REQSYSAUTHOUTFILE server option is set to YES, system privilege is required. If the REQSYSAUTHOUTFILE server option is set to NO, system or restricted policy over the domain to which the node is assigned is required.

You can define (move) a backup set generated on one server to another Tivoli Storage Manager server. Any client backup set that you generate on one server can be defined to another server as long as the servers share a common device type. The level of the server defining the backup set must be equal to or greater than the level of the server that generated the backup set. If you have multiple servers connecting to different clients, the DEFINE BACKUPSET command makes it possible for you to take a previously generated backup set and make it available to other servers. The purpose is to allow the user flexibility in moving backup sets to different servers, thus allowing the user the ability to restore their data from a server other than the one on which the backup set was created. Using the example described in Example: Generating a Client Backup Set, you can make the backup set that was copied to the CD-ROM available to another server by entering: define backupset johnson project devclass=cdrom volumes=vol1,vol2,vol3 description="backup set copied to a CD-ROM"

Managing Client Backup Sets

You can update, query, and delete backup sets.

Task Update the retention period assigned to a backup set Display information about backup sets Display information about backup set contents Delete backup set

Required Privilege Class System or restricted policy over the domain to which the node is assigned Any administrator System or restricted policy over the domain to which the node is assigned If the REQSYSAUTHOUTFILE server option is set to YES, system privilege is required. If the REQSYSAUTHOUTFILE server option is set to NO, system or restricted policy over the domain to which the node is assigned is required.

Updating the Retention Period of a Backup Set

When you want to change the number of days the server retains a backup set, update the retention period that is associated with the backup set. For example, to update the retention period assigned to backup set named ENGDATA.3099, belonging to client node JANE, to 120 days, enter: update backupset jane engdata.3099 retention=120

Displaying Backup Set Information

To view information about backup sets, you can use the QUERY BACKUPSET command. The output that is displayed lists information such as the name of the client node whose data is contained in the backup set as well as the description of the backup set, assuming one has been used. The following figure shows the report that is displayed after you enter: query backupset

+-------------------------------------------------------------------------------+ | Node Name: JANE | | Backup Set Name: MYBACKUPSET.3099 | | Date/Time: 06/09/1999 16:17:47 | | Retention Period: 60 | |Device Class Name: DCFILE | | Description: | +-------------------------------------------------------------------------------+

Displaying Information about Backup Set Volumes

A client's backup set can reside on more than one volume. The server records the information about the volumes used for the backup set in the volume history file. Volume history includes information such as the date and time the backup set was generated, the device class to which the backup set was written, and the command used to generate the backup set. If a backup set spans several volumes, the server displays the command used to generate the backup set only with the first volume. You can view this information when you use the QUERY VOLHISTORY command, with BACKUPSET specified as the volume type. The following example shows how this particular client's backup set resides on three volumes, and the command used to generate the backup set is displayed with the first volume.

+-------------------------------------------------------------------------------+ | Date/Time: 09/24/2001 07:34:06 PM | | Volume Type: BACKUPSET | | Backup Series: | |Backup Operation: | | Volume Seq: 1 | | Device Class: FILE | | Volume Name: 01334846.ost | | Volume Location: | | Command: gen backupset client57 testbs /home dev=file scratch=yes | | ret=2 desc="Client57 backupset" | | | | Date/Time: 09/24/2001 07:34:06 PM | | Volume Type: BACKUPSET | | Backup Series: | |Backup Operation: | | Volume Seq: 2 | | Device Class: FILE | | Volume Name: 01334849.ost | | Volume Location: | | Command: | | | | | | Date/Time: 09/24/2001 07:34:06 PM | | Volume Type: BACKUPSET | | Backup Series: | |Backup Operation: | | Volume Seq: 3 |

| Device Class: FILE | | Volume Name: 01334850.ost | | Volume Location: | | Command: | +-------------------------------------------------------------------------------+

Displaying Contents of Backup Sets

You can display information about the contents of backup sets by using the QUERY BACKUPSETCONTENTS command. When you issue the query, the server displays only one backup set at a time. The server displays information about the files and directories that are contained in a backup set. The following figure shows the report that is displayed after you enter: query backupsetcontents jane engdata.3099

+-------------------------------------------------------------------------------+ |Node Name Filespace Client's Name for File | | Name | |------------------------ ---------- ----------------------------------| |JANE /srvr /deblock | |JANE /srvr /deblock.c | |JANE /srvr /dsmerror.log | |JANE /srvr /dsmxxxxx.log | |JANE ... ...... | | | +-------------------------------------------------------------------------------+

How File Space and File Names May be Displayed

File space names and file names that can be in a different code page or locale than the server do not display correctly on the administrator's Web interface or the administrative command-line interface. The

data itself is backed up and can be restored properly, but the file space or file name may display with a combination of invalid characters or blank spaces. If the file space name is Unicode enabled, the name is converted to the server's code page for display. The results of the conversion for characters not supported by the current code page depends on the operating system. For names that Tivoli Storage Manager is able to partially convert, you may see question marks (??), blanks, unprintable characters, or "...". These characters indicate to the administrator that files do exist. If the conversion is not successful, the name is displayed as "...". Conversion can fail if the string includes characters that are not available in the server code page, or if the server has a problem accessing system conversion routines.

Deleting Backup Sets

When the server creates a backup set, the retention period assigned to the backup set determines how long the backup set remains in the database. When that date passes, the server automatically deletes the backup set when expiration processing runs. However, you can also manually delete the client's backup set from the server before it is scheduled to expire by using the DELETE BACKUPSET command. After a backup set is deleted, the volumes return to scratch status if Tivoli Storage Manager acquired them as scratch volumes. Scratch volumes associated with a device type of FILE are deleted. To delete a backup set named ENGDATA.3099, belonging to client node JANE, created before 11:59 p.m. on March 18, 1999, enter: delete backupset jane engdata.3099 begindate=03/18/1999 begintime=23:59 To delete all backup sets belonging to client node JANE, created before 11:59 p.m. on March 18, 1999, enter: delete backupset jane * begindate=03/18/1999 begintime=23:59

Enabling Clients to Use Subfile Backup

A basic problem that remote and mobile users face today is connecting to storage management services by using modems with limited bandwidth or poor line quality. This creates a need for users to minimize the amount of data they send over the network, as well as the time that they are connected to the network. To help address this problem, you can use subfile backups. When a client's file has been previously backed up, any subsequent backups are typically made of the portion of the client's file that has changed (a subfile), rather than the entire file. A base file is represented by a backup of the entire file and is the file on which subfiles are dependent. If the changes to a file are extensive, a user can request a backup on the entire file. A new base file is established on which subsequent subfile backups are dependent. This type of backup makes it possible for mobile users to reduce connection time, network traffic, and the time it takes to do a backup. To enable this type of backup, see Setting Up Clients to Use Subfile Backup.

Example of Subfile Backups

Assume that on a Monday, a user requests an incremental backup of a file called CUST.TXT. The user makes daily updates to the CUST.TXT file and requests subsequent backups.

The following table describes how Tivoli Storage Manager handles backups of file CUST.TXT. Day of subsequent backup Monday Tuesday

Version One Two

What Tivoli Storage Manager backs up The entire CUST.TXT file (the base file) A subfile of CUST.TXT. The server compares the file backed up on Monday with the file that needs to be backed up on Tuesday. A subfile containing the changes between the two files is sent to the server for the backup. A subfile of CUST.TXT. Tivoli Storage Manager compares the file backed up on Monday with the file that needs to be backed up on Wednesday. A subfile containing the changes between the two files is sent to the server for the backup.

Three

Wednesday

Setting Up Clients to Use Subfile Backup

To enable subfile backup, do the following: On the server: You must set up the server to allow clients to back up subfiles. Use the SET SUBFILE command. set subfile client On the clients: The SUBFILEBACKUP, SUBFILECACHEPATH, and SUBFILECACHESIZE options must be set in the client's options file (dsm.opt). You can control these options from the server by including them in client option sets. For example, you can disable subfile backup for individual client nodes by setting SUBFILEBACKUP=NO in the client option set associated with the client node. See Creating Client Option Sets from the Server for how to set up and use client option sets. See Tivoli Storage Manager for Windows: Backup-Archive Installation and User's Guide for more information about the options.

Managing Subfile Backups

The following sections describe how Tivoli Storage Manager manages subfiles that are restored, exported, imported, or added to a backup set.

Restoring Subfiles
When a client issues a request to restore subfiles, Tivoli Storage Manager restores subfiles along with the corresponding base file back to the client. This process is transparent to the client. That is, the client does not have to determine whether all subfiles and corresponding base file were restored during the restore operation. You can define (move) a backup set that contains subfiles to an earlier version of a server that is not enabled for subfile backup. That server can restore the backup set containing the subfiles to a client not able to restore subfiles. However, this process is not recommended as it could result in a data integrity problem.

Exporting and Importing Subfiles

When subfiles are exported during an export operation, Tivoli Storage Manager also exports the corresponding base file to volumes you specify. When the base file and its dependent subfiles are imported from the volumes to a target server and import processing is canceled while the base file and subfiles are being imported, the server automatically deletes any incomplete base files and subfiles that were stored on the target server.

Expiration Processing of Base Files and Subfiles

Because subfiles are useless without the corresponding base file, the server processes base files eligible for expiration differently. For example, when expiration processing runs, Tivoli Storage Manager recognizes a base file as eligible for expiration but does not delete the file until all its dependent subfiles have expired. For more information on how the server manages file expiration, see Running Expiration Processing to Delete Expired Files.

Adding Subfiles to Backup Sets

When a subfile is added to a backup set, Tivoli Storage Manager includes its corresponding base file with the backup set. If the base file and dependent subfiles are stored on separate volumes when a backup set is created, additional volume mounts may be required to create the backup set.

Deleting Base Files

If a base file is deleted as a result of processing a DELETE VOLUME command, the server recognizes its dependent subfiles and deletes them from the server as well. Subfiles without the corresponding base file are incomplete and useless to the user.