Table of Contents
Advertisement
Keep mount point: The Keep Mount Point setting on each node must be set to Yes using the
command keepmp=yes. This command only works if there are no client sessions running
when enabled.
Update node * keepmp=yes
Replace the asterisk (*) with a node name to update an individual node.
Resource utilization: Use the "resourceutilization" option in your dsm.sys file to regulate the
level of resources the TSM server and client can use during processing. To limit the number
of backup sessions per resource (per tape drive) to one, use the resourceutilization setting of
2; this is equivalent to limiting the VLS to one stream. If you do not limit the number of resources
to one, multiple backup sets will appear in the user interface for a single backup and the
deduplication ratios will be significantly reduced.
Disk pools: A disk pool is a primary storage pool that stores data on disks. When using TSM,
the primary disk pool is typically the initial destination for data being backed up. This storage
pool is sized to accommodate the projected amount of daily changed data in your environment,
as with an incremental backup. The disk pool is typically configured to migrate to the next
storage pool in the hierarchy, the tape storage pool. When TSM migrates data from a disk
pool, it determines what data to migrate based on the node that has the most amount of data
stored in the disk pool. TSM moves the data for each node in the order in which it was written
to the storage pool. The cache feature on the primary disk pool, which is disabled by default,
allows a rapid restore of recently backed up data as necessary.
The recommended option is to eliminate the disk pool and back up directly to the VLS. However,
if you continue using a disk pool for some of your backups (for example, to provide a very
high availability primary pool), the disk pool must be sized to contain the entire night's backup
to ensure good deduplication. At a minimum, the disk pool must be equal to you largest nightly
backup.
Copy storage pools: The copy storage pool provides a way to recover from disasters or media
failures. TSM relies on the process of backing up its primary storage pools to an off-site copy
pool to recover the TSM environment if a disaster (such as the destruction of the data center)
occurs. With a backup of the TSM database in a remote location, the off-site copy storage
pool is a duplicate of all objects in the primary storage pools. Data is stored in a copy storage
pool when you back up active and inactive data in a primary storage pool. A copy storage
pool uses only sequential-access storage (for example, a tape or FILE device class).
The following TSM copy methods will deduplicate successfully in the VLS:
Using "simultaneous writes" to a primary storage pool and one or more copy storage
◦
pools. For example, you could backup to a disk pool and simultaneously copy to one or
more VLS devices, or you could backup to a VLS and simultaneously copy to another VLS.
Copying data from one VLS to another VLS.
◦
NOTE:
In version 3.4, deduplication does not currently support backing up to one VLS
and then copying from that VLS to another VLS. Deduplication is performed on the first
VLS but not the second. This limitation is removed in firmware version 6.0 and higher.
Copying data from a disk storage pool to a VLS. This requires the disk pool size to be at
◦
least equal to your largest nightly backup; see "Disk pools" above.
Co-location: Co-location minimizes the number of tape volumes that need to be written to and
is activated on the storage pool level. If the storage pool that you send backups to is co-located,
then backups are co-located as specified by that storage pool. The greatest degree of
co-location is filespace co-location, followed by client co-location, then co-location groups.
IBM TSM 145
Advertisement
Table of Contents
