Contraste de hipótesis 4

In this section we cover some other subjects which affect all of your client operations.

2.11.1 Scheduling

In our examples of the various client operations, we have shown how they operate from an end user perspective, that is, by using the different interfaces available. In a typical production environment, the backup and other operations which protect the client data should be scheduled, so that we can be sure they regularly execute and can see if or when something goes wrong. Tivoli Storage Manager provides you with a client scheduling interface, which interacts with the server Central Scheduler, for this purpose. Another option for scheduling is to use your own or third party scheduler to run scripts on your clients, comprising the appropriate client commands.

If you use Tivoli Storage Manager’s own central scheduling, the administrator defines appropriate schedules on the server to perform the Tivoli Storage Manager tasks automatically. Central scheduling is a cooperative effort between the server and each client node in that the client must also be running its own scheduler process so that the client and server can contact each other to correctly run the scheduled operation. The client scheduling process should normally be configured to start automatically each time the client boots, to avoid missing schedule execution and compromising data security. There are two methods used to control how the client and server make contact to run a schedule: client pollingandserver prompted. These options and scheduling in general, are discussed further in Chapter 4, “Scheduling” on page 73

2.11.2 Compression

You have the option to specify that each client should compress its files or other objects before sending them to the Tivoli Storage Manager server. Compression is available for both backup and archive operations. Enabling client compression will decrease the network traffic between client and server (because you are sending a smaller quantity of data) at the expense of requiring more client CPU resources to perform the operation. Therefore, the decision to enable client compressions needs to made individually for each configuration. If you are using client compression, then the client will also automatically decompress any objects which are sent back to it from the server when the reverse restore or retrieve operation is requested. Objects which are compressed also ultimately take up less storage space in the Tivoli Storage Manager server storage pools, reducing resource requirements.

If you do not enable client compression, the files will be sent at their full size to the Tivoli Storage Manager server. It is likely that the sequential storage device, for example, a tape drive, can perform hardware compression. If this is the case,

Backup-Archive client 61 you will still get the benefit of reduced space required in the storage pool. Note that if a client has already compressed the files, then a compression-enabled tape drive will not normally be able to compress it further. Compression rates vary considerably depending on the type of data presented.

When using client compression, (compressionset toyes) be aware that some files may actually grow when you try to compress them.This normally happens when the file has already been compressed by some other mechanism like ZIP or TAR and cannot be compressed further. Tivoli Storage Manager detects this condition and you can set options for the client which determine what should happen. You can either roll back the file and send it again without compressing or you can continue the compression operation to completion. Rolling back the file will cause a retry operation to be signalled and will probably increase your backup time if there are a lot of this type of file. On the other hand, forcing the compression operation when it ends up increasing the size of the file means you will be using more space in your storage pools. You should pick the option which best meets your file mix and environment.

2.11.3 Client Authentication

A client is normally required to authenticate itself to the Tivoli Storage Manager server before being allowed to send or receive objects. The mechanism for this is a password, which is associated with each client when it is registered to the server. The password/authentication exchange guards against impersonation on either side by ensuring both that the client is a legimate node and that the server is in fact the real server. The authentication mechanism does not transmit the actual password across the network so there is no risk of interception. The Tivoli Storage Manager administrator can disable authentication completely, which means that no password is required, however this is not normally recommended.

Assuming you are using authentication, the password access option can be set to prompt or generate. If it is set to prompt, which is the default, then the Tivoli Storage Manager server will ask you to supply a password each time you request backup, restore, archive, and retrieve services. If it is set to generate, then Tivoli Storage Manager automatically generates a new password for your client node each time it expires, encrypts and stores the password in a file on the client. The encrypted password will be automatically retrieved from the file whenever you request services. You are not prompted for the password. This option is particularly useful for scheduled operations. As we have discussed in Section 2.11.1, we want to have the scheduler client started automatically whenever the client is booted. Setting the PASSWORDACCESS option togenerate avoids having to manually supply the password or include it in startup scripts. When using the Tivoli Storage Manager Web Backup-Archive client, you also need to set this option togenerate.

© Copyright IBM Corp. 2000 63