Once you have decided that your traditional tape infrastructure is not serving your business needs for backup and recovery particularly well, and that your TSM infrastructure requires some updating, what's next? As I discussed last time out, having the ability to "fix" TSM by dramatically improving the daily schedule, free up TSM server cycles, and enable better business processes—like disaster recovery testing—is a big win.
But change doesn't always come easily.
And particularly change in the form of moving from tape to Data Domain with a TSM server can appear to be a confusing process. After all, for other backup applications that perform periodic fulls, it is "just" a matter of pointing the backup at a new target device, and letting the Data Domain system work its magic. This is almost entirely transparent to the administrator and backup application, and the fact that it is so easy is one of the big virtues of the Data Domain approach.
However TSM doesn't do full backups for many clients, and tapes don't expire in quite the same orderly fashion as they do for other backup applications. (Huge understatement actually. Hopefully no TSM administrators were drinking coffee as they read this as they would likely be trying to get it out of their nose or off their keyboard right now!)
So how do you move, and what is involved?
There are lots of ways to move to a new media pool in TSM, and few of them are outright bad. There is lots of flexibility, so I don't want to present this method as the only one. But my preference is to use a process called "reclaim storage pool". Essentially, this is a process that reclaims the entire contents of a storage pool by moving all valid retained objects to a new storage pool.
So, for the duration of the migration from tape to Data Domain, you will have two principal on-site storage pools (excepting perhaps your disk pool which is the initial backup target). One will be the old tape pool, the other a new Data Domain pool (which could be either virtual tape via a VTL or a sequential disk pool over NFS). Before the reclamation begins, the Data Domain will become the new primary on-site storage pool. All backups will end up here, either directly, if they come from a LAN-Free client, or via migration, if they go to a disk pool first. All new incremental backup data for all clients will go here. Existing retained data will still be sitting in the tape pool.
My preference is to let this run for a week to two weeks to begin to capture the most recent active data, and let a portion of the data on tape expire. Every little bit helps.
Then we begin the reclaim process on the (old) tape storage pool. Reclaiming across storage pool works exactly like reclaiming within a storage pool—except that the valid retained objects will be moved to the new pool. That is, they will end up on Data Domain rather than just another tape. The advantages of using this process are several:
- You can interrupt it at any time or cancel it at the console with absolutely no impact (it can be resumed after an interruption without having to start over).
- It is the same process already used to reclaim space within a storage pool, and therefore its impact and management is already well understood by most TSM administrators.
- It can be done gradually: by gradually increasing the reclamation threshold, you can cause the process to run incrementally. By starting at 90%, then 80%, then 70% and so on, we can gradually move over portions of the valid data in a measured fashion. (You may want to do this by identifying all the volumes that fit the criteria, then reclaiming those volumes too.)
- You can exercise as much or as little fine grained control over the migration as you like. Although the steps above are certainly a good idea, in principle, there is not a lot wrong with just setting the reclamation on the old storage pool to 0 (forcing everything to be reclaimed) and letting it go.
It is all as simple as designating the Data Domain as the target for reclaim storage pool: your syntax will determine the storage pool which is the source, the reclamation threshold value, the pool which is the target (Data Domain) and the number of parallel processes (generally as many as you would typically use for reclamation). And that’s it.
All of which brings us to the next part: what are the things to look out for in a TSM migration from tape to Data Domain? That’s up next time.
Comments