What you will learn from this tip: This is the second in a four-part series on IBM's Tivoli Storage Manager (TSM) backup software. This segment outlines some of the best practices when designing and implementing a TSM backup environment.
There are many aspects to consider when deploying an IBM Tivoli Storage Manager (TSM) backup environment. Beyond the basic requirements common to most backup products, such as network bandwidth, I/O performance, tape throughput, etc., some are TSM-specific based on product architecture. The following are generally accepted best practices regarding some infrastructure design and implementation items specific to TSM.
Disk pool sizing
TSM can use disk storage pools to stage backup data and later migrate it to tape. Among other things, this allows for simultaneous backup sessions without requiring a large number of tape devices or resorting to data interleaving or multiplexing on tape (more on TSM integration with disk next month). The disk pool(s) must be large enough to hold at least the equivalent of one night's worth of backup data that is directed to disk. Otherwise, data migration to tape might be triggered automatically instead of on schedule and interfere with other processes.
((Content component not found.))
Tape subsystem sizing
The tape subsystem must be sized to hold all the backup data to be kept onsite. Lack of capacity will force the ejection of full tapes to make room for empty (scratch) tapes. This practice interferes with TSM's automated data management processes. Capacity must consider onsite backup data, scratch tapes and growth.
The tape library should also be configured with enough tape devices to accommodate all direct backups to tape, data migration, storage pool backups for offsite, tape reclamation and restore requests for any given daily cycle.
Storage pool collocation
Collocation is TSM's ability to store data from different systems on separate tapes (the opposite of multiplexing). However, collocation can result in poor media utilization when backing up smaller systems and seriously impact library capacity.
Backup data change rate and retention
The rate at which data changes and how long backup data is retained are the most important factors to consider for TSM capacity planning. The amount of daily backup data dictates network capacity, server performance, staging disk pool requirements and the number of tape drives when backing up directly to tape. How long backups are retained has a direct influence on the tape library capacity.
TSM database and logs
The TSM database must be backed up at least daily and ideally twice with one copy sent offsite and the other kept onsite for rapid restores. If roll-forward logging mode is enabled, there must always be scratch tapes available for database backups to avoid having the logs reach the 13 GB limit, which will force a TSM hard stop.
Storage pool backups
All primary disk and tape storage pools must be backed up to the copy storage pool on a daily basis. Copy pool tapes (and database backups) should be sent offsite daily to avoid keeping all backup data in one location over extended periods.
Backup agents for applications
The "cowboy backup" method (two-step) should be avoided when backing up applications like MS SQL or other databases. This consists of creating a database "dump" to disk and subsequently backing up the flat file. TSM has backup agents that integrate with applications to perform hot backups.
Scheduling
In addition to client backups, all TSM administrative processes should be automated using the central scheduler to avoid errors and omissions. This includes processes, such as expiration, storage pool backups, migration, reclamation and database backups, all of which must be scheduled in order. Ideally, the last TSM processes in a daily cycle prior to vaulting should be the TSM database backup, closely followed by the volume history file backup and disaster recovery manager (DRM) file preparation to capture the latest system state information.
Disaster recovery manager
The DRM module of TSM should be fully configured with all "Instructions" files duly documented and maintained. Every time the TSM "prepare" process is run (should be daily), the DRM produces a TSM recovery plan file, which contains all the TSM configuration information along with a list of offsite tapes and database backup volume. This information is essential to recover the TSM server in the event of a total failure. Obviously, the DRM plan file must be sent offsite daily with the copy storage pool tapes and database backup.
More information on TSM architecture and concepts can be found in the IBM Tivoli Storage Management Concepts Redbook (SG24-4877). Next month, we will discuss TSM integration with disk (native, backup appliances and VTLs).
About the author: Pierre Dorion is a certified business continuity professional for Mainland Information Systems Inc.
 |
|
Rate this Tip
|
To rate tips, you must be a member of SearchStorage.co.UK.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
