BackHome!/TSM and LARGE OBJECT BACKUPS

Some considerations should be taken into account when backing a very large file to a Tivoli Storage Manager (TSM) server. Because BackHome!/TSM stores the output of the Tandem BACKUP utility in the TSM server the object/file tends to be very big in opposition for example to most files backed up from an N.T. server

ETINET recommends splitting up your backup job into a few medium size backup requests instead of one large backup in order to take full advantage of your communication line capacity. The number of jobs is up to you but they should be more or less equal in size along with a multiple of the number of requesters connected to your TSM server.

NOTE: It is not always possible to split up a backup job.

For Example: A big TMF Online Dump is not possible to split up

The following are suggestions that may help when planning to store a very large file on the TSM server.

Storage on the Tivoli Storage Manager Server

Tivoli Storage Management Software has several different ways to manage files within the system. The most efficient way to manage large files within the TSM server is to do the following..

1. Create a separate Diskpool on the TSM Server for the Tandem client. This disk pool will handle the BackHome files sent to TSM to manage. The disk pool (called TANDEM) for example can be any size, but it would be optimal to have it large enough to handle a full file backup. Since space for disk pools are always an issue it doesn’t have to be that large. The larger the better but it will work with any size.

   NOTE: Recommended size is 10% of the file in question, of possible

   This pool will need a NEXT STORAGEPOOL assigned to it as well. This next storage Pool should be a tape pool. This next pool does not have to be dedicated to TANDEM, it can be the same tape pool used by everyone.

2. The disk pool will need to have a migration process set up. The migration process helps control the amount of free space within the storage.

3. There two controls that can be used to manage the disk pool, they are:
   • MAXSIZE
   • MIGRATION

   If you assign MAXSIZE (see OBJECTSIZE below) to the storage pool, files placed in that storage must be equal to or less than the assigned maximum size requirement for that pool.

   APPROACH NOT RECOMMENDED

   If files are larger than MAXSIZE than they will go directly to the next storage pool assigned. This will work but it may time out the BackHome transfer process due to tape mounts for sequential tape.

   ** ETINET RECOMMENDS MIGRATION TO CONTROL DATA FLOW **

4. The Migration process will have to be managed with a high or low threshold in order to manage data movement. The migration should be set as follows:

   Update stgpool tandem highmig@lowmig

   This will set a trigger for the migration to start as soon as 40% of the disk pool is full and to stop migration when the low threshold reaches 10%. These numbers can be increased or decreased as the size of the disk pool is increased or reduced.

   By using migration to handle the process of moving data to disk and tape the BackHome!/TSM will not be interrupted waiting for tape mounts. The backup on the tandem system will continue to be passed to BackHome!/TSM for transfer at the rate available over the connection to disk. The TSM backup process runs as one process to handle management of the backup and the migration process runs as a separate process to handle the movement of data from disk to tape OUTSIDE of the backup process. Migration will call for tape mounts and handle interruptions. The backup will run uninterrupted to disk.

Recover Log

The database, recover log, and storage pool volumes are closely related. The TSM database contains information needed for server operations and information about client data that has been backed up archived and space managed.

NOTE: Client data itself is stored in storage pools, not in database

The database contains pointers to the locations of all client files in the TSM storage pools. Changes to the database are recorded in the recovery log in order to maintain a consistent database. These changes are the result of transactions between clients and the server. Examples of activities that can occur in a transaction:

• defining a management class or copy group
• archiving or backing up a client file
• registering an administrator or a client node

THE DATABASE CONTAINS:

• Information about client nodes and administrators
• Policies and schedules
• Server settings
• Location of client files on server storage
• Information about server operations (for example : activity logs and event records )

The RECOVERY LOG contains information about updates that have not yet been committed to the database.

The recovery log maintains data for point and time recovery. The user may have the recovery log set to roll forward. If that is correct than there is no real way to estimate in advance the size needed for the recovery log. If the log is set to normal (which is the default) then the recovery log should be made as large as possible.

IMPORTANT

DO NOT EXCEED 4GB

Since the maximum size of the recovery log is 4.5GB. You will need the extra to recover the server in the event it crashes. While executing a large dump, there me be a long time and a lot of change to the database before a commit is made by BackHome!/TSM

For this reason it is recommended that for normal backup, the checkpoint/restart option be used. This way a commit will be sent for each checkpoint. For TMF however, it is not possible. We recommend that that the recovery log is allocated as big as possible.

OJECTSIZE

[Estimated Object Size]

The TSM server requests an estimate of the size of file at the beginning of the transfer. BackHome!/TSM provides the attribute OBJECTSIZE to set this value in the request definition . When checkpoint is enabled in a backup request, the estimated object size sent to the TSM server is accurate. It is the greater value between the checkpoint size and the size of the Guardian file coming in the backup data-stream and the value given to OBJECTSIZE will be ignored .

This optional attribute is valid for a Backup. It specifies in megabytes, the estimated size of the object that will be stored on the Tivioli Storage Manager server. This value helps TSM server to manage the storage pool where the object is stored, especially when the object will not fit in the available space and when a migration pool is not available.

If the server can not accept the size given the request will ABEND at the beginning instead of stopping in the middle of every large backup. The default value is 5 megs.

EXAMPLE : SET REMOTE-ATTR01 OBJECTSIZE = 2000