A properly designed Tivoli Storage Manager (TSM) server is absolutely essential to having a solid system that can meet your business continuity, disaster recovery (DR), and “Oops, I deleted the wrong file” needs. In part 1 of this series, I gave an overview of TSM and its nuts and bolts. In this article, I'll show you how setting up your TSM server correctly the first time will give you the greatest success in maintaining, administering, and growing your TSM environment.
Before you even touch your server, you should take the time to look at your environment and ask the following basic questions.
How much disk space do my clients use? In a world where 100 web servers can consume less disk space than a single data warehouse system, and where it’s faster to reinstall applications than it is to recover them, this initial question is designed to get you thinking about just how much mission-critical data needs to be retained and how big your environment needs to be.
How many versions of that data will need to be retained? Will your customers and users require you to hold multiple copies of their files for years and years, or will they need a single recent backup image for their purposes? What about government regulations on storing data? You’ll need to think about version retention as you plan out your long-term vision.
How much of the data needs to be accessible on disk? The advantages of disk storage pools are that backups and restores are faster, and the data is more available. But disk storage is expensive and can’t be transported offsite for backups. Ask yourself how you’ll use disk storage: Will you use it as a temporary landing pad before going to tape, or as a more versatile medium?
How much of the data needs to be accessible on tape? Tape storage is inexpensive and portable, which makes it an ideal technology for backup and archival purposes. But it can be slow and unwieldy, especially as prior versions of data expire, leaving small quantities of pertinent tape data for libraries to recover. How will you use tape storage?
How much of that data will need to be sent offsite in case of a disaster? What data is truly needed if all of your systems die? In some environments I’ve worked in, only a small subset of data was needed for business continuity purposes because most of the data could be reinstalled or re-created from scratch. Other environments required a complete replica of every facet of the servers available on tape. You’ll need to determine with your business how to manage your offsite resources.
TSM Server Requirements
After you’ve taken a rough estimate of the scope of your backup environment, there are a few things you’ll need to set up your TSM server. The first is the TSM software itself. This can be obtained through IBM’s Passport Advantage website or by ordering base media on CD-ROM with a license. The installation media comes with a ton of packages; at a minimum, you’ll need to install the server runtimes, licenses, C++ runtimes, and device packages.
The second thing you’ll need is enough disk storage. This should account for all of the versions of the backups and be large enough to store at least two days’ worth of backups in case your tape library is offline. The storage should be compartmentalized into different areas, such as file systems on AIX, for storing specific types of data and the TSM database and log.
The third thing you’ll need is tape storage. IBM has a wide variety of tape libraries available that can be directly attached to a server or hooked up over a SAN. After connecting the devices to the TSM server, you’ll usually see some rmt devices for the tape drives and an smc device that acts as a controller for the automated robot picker in the library. You’ll also need enough scratch (blank) tapes to hold your data for offsite storage purposes.
Defining the TSM Resources
Once you have everything prepped for your server, it’s time to define all the resources within TSM. The command to access the administrative menu system on AIX servers is dsmadmc and the default user ID is admin. Commands issued within the administrative interface tend to follow a database-like command format with less emphasis on flags and more of an intuitive, sentence-driven structure (e.g., set servername and set serverpassword, which should be run after initially logging in).
The two handiest commands to know are help and query. You can pass a command name as an argument to help, such as help define, and TSM will list all possible commands and options using that particular string. The query command can be used to look at almost every possible item within TSM, from retention periods to the last person who logged in to the server. Almost all of these commands can be shortened (e.g., q for query, descr for description). The help command accentuates these shortcuts in capital or bold letters.
TSM Database and Log Definition
The first things that need to be defined are the TSM database and log. The database tracks all the meta information within TSM and the log captures events that happen between TSM database backups. These should first be carved out on the AIX command line with the dsmfmt command to establish the files that will be used to hold this data, and then declared within the TSM server with the define command. Common commands used to define the TSM database and log are dsmfmt, define dbvol, and define logvol.
Tape Library Configuration
Next, it’s time to tell TSM where to find its tape resources. To do this, you’ll need to tell the server its library and drive names. Then you’ll need to define the path information and tell TSM how it should access those resources, such as teaching it which tape drive corresponds with which library (even if there’s only one). You’ll also need to tell TSM what type of device class the tape library is (e.g., a 3494 library or a generic tape library). Common commands used to find tape libraries are define library, define path, define drive, and define devclass.
Tape Pool Configuration
Now that the library has been defined, individual tape pools should be carved up. The size of the tape pool is governed by the maximum number of scratch tapes that the pool can contain. Each one of these tapes is commonly called a volume. In addition, two other settings are defined here: the reclamation threshold, which tells TSM when it should combine the information held on two or more tapes together onto a blank tape in order to consolidate and save space, and colocation, which keeps data as contiguous and isolated as possible. Use the define stgpool (tape) command to define tape pool configuration.
Disk Pool Configuration
Disk pools should be defined to specify how TSM can store data on hard drives and SAN resources. I’ve found that the easiest way to do this in AIX is to allocate complete raw logical volumes to TSM and let it manage how it uses that space as TSM volumes. Disk pools can also be configured with high and low water marks for migrating data onto the next storage pools in line (highmig, lowmig), which will cascade data down onto tape (nextstgpool). Common commands to define disk pools as volumes are define stgpool (disk) and define volumes.
Copy Pool Configuration
For offsite storage or for extra redundancy, additional copy pools can hold identical copies of backups and archives. My preference is to spool off disk pools to tape, have the system make a copy on separate tapes, and eject those tapes for sending to a DR location. Use the define stpool (pooltype=copy) command to copy tapes.
Policy Domains, Policy Sets, Management Classes, and Copy Groups
After all of the resources have been defined on the TSM server, it’s time to tell the system where clients can back up their data. This is done through hierarchical policy management. Policy domains are areas to which clients belong. Policy sets allow administrators to come up with many different ways the system can retain data, although only one policy set can be active at a time (most admins create only one per domain). Management classes can contain backup and archive data for the different clients. And copy groups are where the rubber meets the road—where TSM is told how many versions, how many deleted copies, how many days, how often, and in what storage pools the backups and archives can be held. The define domain, define policyset, define mgmtclass, assign mgmtclass, define copygroup, and activate policyset commands define domains, sets, classes, and groups.
TSM Server Is Ready for Clients
After all of these steps are complete, the TSM server is ready for backups and to have clients communicate with it. In my next article, I’ll cover registering clients, telling them what data to include and exclude, and conducting incremental test backups.