TSM client node data can be incrementally replicated from a source replication server to a target replication server. If you lose your source server and cannot get it back, you can convert the clients on the target server to non-replicating nodes and resume the backup and recovery service from your target server.
Note that the client node data is incrementally synchronized, so once the first backup is replicated, only changed data is transferred. The amount of data transferred can be further reduced by using deduplication. If you already have a copy of a node, created by an export - import process, you can convert the nodes to replicating nodes.
Node replication applies to TSM 6.3 servers, but the TSM clients can be earlier versions.

Deduplication of data that belongs to network-attached storage (NAS) file-servers is disabled by default. To enable deduplicaton of NetApp file-server data, use the new ENABLENASDEDUP server option.

If automatic table and index reorganization is affecting server performance, you can manually schedule reorganizations.

You can automatically schedule version upgrades to TSM clients, provided that they are at least at client level 5.5. You schedule and control the updates from the Administration Center.

You can use several concurrent data streams when backing up a TSM database. You can then restore the database with up to the same number of data streams. Each data stream will use a separate tape, so it is a question of balancing backup and restore speed against resource utilisation. This feature is expected to be used for large TSM databases, say over 150GB.

One of the issues with IBM Tivoli Monitoring was the time it took for the initial configuration. IBM has addressed this with an improved installation wizard, and by including Cognos Business Intelligence V8 as an integrated business intelligence suite.
The monitoring dashboard can be customised to display the items you most want to see, in a single view. The default setting shows the storage space used by node; unsuccessful client and server schedules; and details about storage pools, drives, and activity log error messages.

TSM licensing and Processor value units has been an issue for a long time. IBM provides a new command, QUERY PVUESTIMATE that you can use to report on the number of server devices and client devices managed by a TSM server. IBM says that 'these reports are not legally binding, but provide a starting point for determining license requirements'.
An SQL query, SQL SELECT * FROM PVUESTIMATE_DETAILS can also be used to extract data at node level.

It is now possible to define a library as a virtual tape library, which means improved mount-point processing to better handle large numbers of virtual drives

You can now format volumes on LINUX ext4 file systems and AIX JFS2 file systems nearly instantaneously, similar to the way Windows disks are formatted in older TSM server releases.

It is possible to migrate a TSM server running under z/OS to a 6.3 server running AIX or LINUX on system Z, and provided the tape drives are connected with FICON channels, the old tape data can be read from the new server. This requires a TSM for z/OS Media module.

The CHECKTAPEPOS server option is enhanced to check for data overwrite problems before each WRITE operation and allow Tivoli Storage Manager to reposition tapes to the correct location and continue to write data.

Persistent reservation allows tape drive reservations from other servers to be cleared, if, for example, a server crashes. In TSM Version 6.3, persistent reserve is enabled for drives that support it.

Numerous enhancements have been made to the TSM Administration Center, including the ability to monitor using IE8 or Firefox 3.5, and enhanced wizards for defining policy domains and management classes. You can also get specific performance information about TSM clients, such as processor usage, Network utilisation, data throughput rates and more.

Backup-archive client updates

You can upgrade or refresh Linux client software using the rpm commands rpm -U and rpm -F. There is no need to uninstall files before performing an upgrade.

Linux now supports journal-based backup on all local file systems.

The maximum path length that in supported by the Backup/Archive client on Linux has been changed to 4096 to match the PATH_MAX supported by the operating system.

The TDM 32 bit API is not shipped anymore, so Backup-Archive Clients and the API for Linux, MAC and Solaris SPARC are now shipped as 64-bit applications.

There is a new Windows client configuration wizard to simplify the configuration of MSCS cluster disks, and propagate the configuration to other nodes in the cluster group.

You can now perform full VM backups and full VM incremental backups and restores from a Tivoli Storage Manager agent node on a Linux computer.

In Tivoli Storage Manager version 6.3, you can now use the Filelist option with the snapshotroot option on incremental, selective, or archive operations. Using these two options, together, was not allowed in previous versions.

VMware supports pRDM, or raw device mapping disks that are provisioned in physical compatibility mode. If you tried to backup a VMware machine that used these devices with TSM 6.2 or earlier the backup failed. TSM 6.3 cannot back these devices up either, but you have a new options, VMPROCESSVMWITHPRDM which can be used to allow backups of volumes that support snapshot operations. The same principle applies to independent disks, and they have a new parameter, VMPROCESSVMWITHINDEPENDENT.

The SQL TDP has a new GUI, configuration wizards and a new dashboard that gives you a graphical picture of what is happening in your SQL estate. Statistics now include compression, encryption, LAN free and de-duplication information. Youi can also use native SQL compression with a new SQLCOMPresssion option.

The Oracle TDP can also get compression, de-duplication and encryption data from the tdposync command. Tdposync now has an option, syncdb, that can be used to synchronise the TSM database with the Oracle RMAN catalog.

TSM 6.2 New Features

Data Deduplication

Data deduplication was driven from the TSM server in TSM 6.1. With TSM 6.2, the deduplication can be driven from the client side, so reducing the amount of data going over the network. The only restriction is that the target primary storage pool must be sequential-access disk.

6.2 clients will be able to access and reconstruct data that was created by server-side 6.1 de-duplication.

Simultaneous-Write Operations

TSM will write data simultaneously to copy storage pools and active-data pools during server data-migration processes.

Automatic Backup-Archive Client Deployment

You can distribute code to TSM windows clients from the V6.2 Administration Center to workstations, provided that code is 5.4 or higher, using configuration wizards.

Encryption Using SSL

You can use Secure Sockets Layer (SSL) to encrypt all the traffic between TSM servers and UNIX and Windows clients

SCSI Passthru Support

TSM 6.2 supports SCSI passthru, which means you can use a Windows certified device drives, instead of the TSM device driver. In the fixpack notes for TSM 6.2.1, IBM states " It is recommended to use the Windows native device driver instead of the Tivoli Storage Manager device driver when the Windows native driver is available for your device."

Concurrent Read/Write Access to Centera

Previous TSM versions scheduled all IO to Centera volumes serially, so if anything was using a volume, other processes had to wait. TSM 6.2 will now schedule some concurrent access, limited to one write session and multiple read sessions. This has obvious advantages for concurrent restores and will also speed up client exports and backup set generation.

A New Graphical User Interface

The ISC has been replaced by a new IBM Tivoli Integrated Portal. To be honest, the ISC was such a pain to use that most people just adopted the TSM specific command line approach, so it's hard to get excited by yet another all-singing, all-dancing Tivoli GUI.

MOVESIZETHRESH Option

The MOVESIZETHRESH server option default/maximum values have been increased from 2048 to 4096; and the maximum value has also been increased from 2048 to 32768. This specifies the amount of data moved as a batch, within the same server transaction, so increased sizes should improve server efficiency.

CHECKTAPEPOS Option

CHECKTAPEPOS is a TSM server option. The default option is checktapepos yes, and then TSM will check the validity and consistency of the position of data blocks on tape after it writes data. If the server information about position does not match the position detected by the drive, an error message is displayed, the transaction is rolled back, and the data is not committed to the database.

Sun StorageTek T10000B drive encryption

TSM 6.2 supports tape device encryption with Sun StorageTek T10000B drives.

VENDOR Showcase