TSM on System i Information and Considerations

By Nancy Roper Executive Overview This document has been written to help customers understand the Tivoli Storage Manager (TSM) products on the System i platform and understand why the TSM Client solution is often not the best choice for System i backups. The TSM product has multiple components. The two key ones are the TSM Client that gathers data from distributed systems and the TSM Server that catches the data from the clients and saves it. TSM Server: On System i, Tivoli no longer offers a native TSM Server product. Customers should choose a TSM server that runs on another operating system. If desired, customers could run the TSM server on a Linux, AIX, or Windows environment running on System i hardware. Appropriate tape support should be verified as part of the solution design process. TSM Client: On System i, the TSM client is offered via the BRMS product. Customers create their backups as usual in BRMS, but direct them to the TSM Server rather than a tape drive. However, this solution has a number of significant considerations, that make it a poor choice in most customer environments. The three key considerations are as follow: (1) Performance is dramatically less than current technology tape drives (eg 32 GB/hr on TSM vs 650-890 GB/hr on current technology tape for largefile saves) (2) This solution only saves user data, not system data, so tape drives and tape management procedures are still needed to handle the system saves (3) The BRMS database must be backed up following each save and moved to a safe place (eg saved to tape or FTPd to another system with appropriate procedures), otherwise the system is *NOT RECOVERABLE* Customers are encouraged to understand the considerations related to the TSM client backups prior to embarking on that strategy. Typically they will find that a traditional tape backup strategy is a better choices for their System i data.

Copyright 2007, IBM Corporation http://www.ibm.com/support/techdocs

Version 1/1/2012 Page 1

TSM on System i - Information and Considerations TSM on System i - Information and Considerations

Introduction Tivoli Storage Manager (TSM) is a product that offers an enterprise-wide solution for backing up distributed systems. It was formerly known as ADStar Distributed Storage Manager (ADSM). TSM clients send their data across the network to a TSM Server. The TSM server then replicates the data to a remote server, and/or saves the data to tape. LAN-free solutions are available for some platforms. Key benefits of TSM are as follow: (1) The wide variety of platforms supported (2) The ability to do incremental always saves on many platforms, thus reducing the amount of data that needs to be transmitted each day (3) The ability to have multiple systems running saves simultaneously, without needing a separate tape drive for each one TSM Server on System i Starting in the mid-1990s, there was a native TSM server that ran on System i. It could be used to pull data from smaller systems, typically desktops and Windows servers, to the System i, then save the data to tape. However, once System i began supporting other operating systems on the same hardware, it made sense to amalgamate development and direct System i customers to use a TSM server running on another operating system. Customers had the option of running that TSM server natively, or if it was AIX, Linux or Windows, it could run on System i hardware. Customers who choose to run the TSM server for AIX, Linux, or Windows on System i hardware should make sure they understand the tape connectivity options for their configuration, particularly if they plan to share a tape drive between i5/OS and the guest partition. TSM Client on System i Some customers are interested in having a common backup environment for all their systems. These customers would like to send their System i data to a TSM server elsewhere in their organization, ie they would like to use the TSM Client for System i. This client is implemented via BRMS. Customers use BRMS to set up their backups in a very similar fashion to native saves. However, they direct their saves to a TSM server rather than sending them to regular tape drives. This solution has a number of considerations that customers need to understand before going forward. In most cases, customers find that these considerations are show-stoppers, and realize that a regular BRMS implementation using native tape will give them a far better save/restore solution. A summary of the considerations is as follows:
Copyright 2007, IBM Corporation http://www.ibm.com/support/techdocs

Version 1/1/2012 Page 2

TSM on System i - Information and Considerations TSM on System i - Information and Considerations

(1) Performance (2) User Data Only (3) Saving the BRMS Database (4) Incremental Always saves not recommended (5) BRMS / BRMS skills required (6) Messages are viewed via BRMS (7) Scheduling via i5/OS (8) Site Loss Recoveries We will now explain each of these considerations in detail. The first three are usually the ones that cause customers to decide against the TSM Client solution. (1) Performance The TSM client runs at dramatically slower speeds than native tape. Benchmarks were run several years back when the 170 was current product line, and again when the 820 was announced. Results are at the following url: http://www-03.ibm.com/servers/eserver/iseries/service/brms/adsmperf.html If you roll down to the bottom, you can see the 820 benchmark that uses 1 Gbit ethernet. Notice that even a largefile save (1 GB libraries) only runs at 32 GB/hr (yellow bars). Compare that with the System i largefile save benchmarks (4 GB members) for LTO4 (650 GB/hr) and TS1120 (890 GB/hr) drives. Although the TSM client performance has improved with newer generations of CPUs, it is still an order of magnitude slower than the native BRMS/tape solution. Notice that restore performance (green bars) is significantly less than save performance. Notice that the benchmark also shows figures for an infinite network (red bars) where the save/restore APIs were modified to save the data to disk rather than sending the data across the network to the TSM server . The fact that these saves were much faster suggests that the network and TSM server were the bottleneck in the benchmarks, not the System i or BRMS. Notice, however, these figures are also much slower than saves to native tape. (2) User Data Only The TSM client solution is only able to back up user data. This makes sense, if you think about the restore. In order to connect to the TSM server to get the data, you need to have a system that is loaded with the operating system, including user profiles and configuration data, TCP/IP communications, and BRMS, etc, so obviously those files need to be saved somewhere *other* than the TSM server. Note that this system data is typically saved after release upgrades, PTF installs, and anytime that the configuration or user profiles change.
Copyright 2007, IBM Corporation http://www.ibm.com/support/techdocs

Version 1/1/2012 Page 3

TSM on System i - Information and Considerations TSM on System i - Information and Considerations

On other platforms such as Windows desktops, people are willing to re-load this code from their CDs, then reapply fixes, and re-do their configuration and user profile setup. However, on a system as large as System i, this would not be reasonable. Hence TSM client users need to have a tape drive attached to the system in order to save their system data, and they need procedures to move this tape to a safe offsite location. By the time they have this much in place, its often simpler just to do the entire daily save to this same tape drive, particularly in light of the other considerations listed. (3) Saving the BRMS Database For most TSM client platforms, the index to the files saved is stored in the TSM database which is located on the TSM server. So if the client needs to be reloaded from scratch, you need to reload the operating system, user profiles, configuration, etc, and then connect to the TSM server and the TSM database will help locate the user data needed for recovery. On System i, the file system is enough different that we were not able to store our index in the TSM database. Instead, this information is in the BRMS database which resides on the TSM client. This presents a problem if the System i needs to be reloaded from scratch since the BRMS database needs to be recovered *before* connecting to the TSM server. Because the BRMS database changes with every save, that means that it needs to be stored in a safe place after every save ... eg saved to physical tape, or FTPd to another server that will be available when a recovery is required. Note that the FTP option is not recommended since it is cumbersome to track the copies of the BRMS database on the second system, and it is not possible to FTP the BRMS database back following a failure since the failed system does not have enough code to do FTP at the time the BRMS database is needed for the recovery. Instead, the proper version of the BRMS database needs to be saved to tape and moved to the recovery site to be included in the reload. Saving the BRMS database is similar to the challenge in saving the system data in (2) above, except that the BRMS database needs to be saved much more frequently. Also, it is possible, just not palatable, to recreate the system data from CDs and by rekeying. However, if the BRMS database is missing, then there is no way to get at the data stored on the TSM database and the system is not recoverable. Customers often dont understand the importance of this point. They set up the TSM client, then do a test restore of a single file or library, and conclude that the restore works. They dont realize that this is because the BRMS database was available on their system. If they had had a complete system failure that required a scratch reload, they would need to produce an up-to-date copy of the BRMS database, otherwise their system would not be unrecoverable. (4) Incremental Always Saves not Recommended
Copyright 2007, IBM Corporation http://www.ibm.com/support/techdocs

Version 1/1/2012 Page 4

TSM on System i - Information and Considerations TSM on System i - Information and Considerations

The file structures/relationships and recovery procedures on other platforms make it possible to do incremental always saves, thus reducing the amount of data that needs to be sent to the TSM server each day. On recovery, only the latest copy of each file needs to be restored. By comparison, System i recommends periodic full saves, typically weekly, since our restore procedures restore every file on the incremental tapes, even if it is going to be overlaid by the next days save of that file. People who are familiar with TSM but not i5/OS are often surprised by this fact, and caught off guard by the amount of data that will need to be transmitted to the TSM server on weekends. (5) BRMS / BRMS Skills Required Most of the TSM clients have a common GUI interface, so staff are very comfortable using the interface on a variety of different platforms. People who are looking for a common enterprise-wide backup environment are often surprised to learn that they need to purchase BRMS for each System i in their environment, and that staff will need to be familiar with BRMS in order to setup and run the backups (6) Messages Viewed via BRMS Most of the TSM clients log their backup error messages in the TSM log. This means that staff can look in one place each morning to check the status of all backups. Because System i is a much larger system, with much more extensive messaging to help identify/understand problems with a backup, the bulk of the messages are logged in the BRMS log and other areas of i5/OS. Only minimal messages are logged in the TSM message log. People who are looking for a common enterprise-wide backup environment are often surprised to learn that staff will need to look in both places to investigate any backup issues. They are also typically impressed by the detailed nature of the System i messages. (7) Scheduling via i5/OS TSM offers a centralized scheduler that is typically used to schedule backups for other platforms. However, this scheduler does not support System i. System i backups are initiated from the System i client using the BRMS backup commands. Customers will often incorporate the saves into their regular automated job stream via the base scheduler (WRKJOBSCDE), or the Advanced Job Scheduler program product.

Copyright 2007, IBM Corporation http://www.ibm.com/support/techdocs

Version 1/1/2012 Page 5

TSM on System i - Information and Considerations TSM on System i - Information and Considerations

People who are looking for a common enterprise-wide backup environment are often surprised to learn this. They are also typically impressed by the extensive capabilities of the System i schedulers. (8) Site Loss Recoveries We have already discussed single-system recoveries from scratch, where it is important to have copies of your system saves and BRMS database saves in order to recover. However, customers also need to consider a site-loss recovery scenario when using an enterprisewide TSM backup solution.. In this case, step 1 is to recover the TSM server. Simultaneously, you can recover your System data and BRMS database to your System i from tape. If you FTPd your BRMS database to another system, you will need to link to that system to restore the BRMS database, as soon as it is up and running again. Thereafter, all platforms will need to compete for TSM server resources (CPU, disk, memory, tape drives, etc) in order to recover their data. Recall that TSM client restore speeds on System i are very slow compared to native tape. Contrast this to a native backup strategy to BRMS/tape where the System i can be recovering simultaneously with other systems without contention, and with good restore speeds, and with the automation provided by the BRMS recovery functions. Conclusion System i does not have a native TSM server product. Customers who are embarking on a TSM project will need to choose another operating system to run their TSM server on. If they choose AIX, Linux, or Windows, they can then consider running the server on System i hardware if desired. They should plan to verify the tape connectivity options for their chosen environment as part of their project. System i customers who are interested in the TSM client for saving System i data to a TSM server should ensure they understand the considerations listed in this document. They should plan to do a pilot project to understand the performance and usability in their environment. They need to make certain they have a plan to save the system data and BRMS database as needed so they can do a successful full system recovery from scratch.

Copyright 2007, IBM Corporation http://www.ibm.com/support/techdocs

Version 1/1/2012 Page 6

TSM on System i - Information and Considerations TSM on System i - Information and Considerations