I thought I would wrap up my thoughts on TSM, for now, by talking briefly about two things TSM users are typically concerned about: migrating TSM clients and getting off TSM.
The first one of these is something we talked about just recently. And I think I covered off the easiest way to move to a Data Domain target with TSM from a tape or virtual tape target. But one of the things I frequently get asked about is: what about clients backing up using client side compression?
This practice seems to be relatively common amongst TSM users—I could speculate why, but I won’t. Suffice it to say that it is far more common in TSM environments than it is for users of other backup applications. And it is a pernicious practice that is just not good. In any way. Sure it saves bandwidth. Sort of. But bandwidth is free, more or less. And it isn’t a big enough deal to enable remote backup, so really it just saves local bandwidth. Which is even closer to free.
But aside from that, it kills deduplication. (And no, not just deduplication on Data Domain, deduplication on anything.) Because, you see, TSM client compression stays with the backup object for as long as that object is retained. Meaning that even if you turn it off, only future versions of backup objects will be backed up without compression, and all the existing versions in your TSM storage pool will remain compressed. Where they will deduplicate poorly, or not at all.
So, for all of you using TSM client compression, here is my advice: turn it off now. Right now.
OK, have you done it? Good.
No such thing as soon enough here.
Because at the end of the day, you will be moving to a dedup target, if you haven’t already. Sooner or later you will. It is inevitable. Just like death and taxes. Only a heck of a lot more pleasant than either. And the best thing you can do to prepare for this future is stop using client side compression now. At least that will minimize the amount of retained compressed data that will not dedup well.
The other issue here is how to get off of TSM. We have a large number of clients that have done this and are doing this, and one big question that comes up is: what do I do with my retained data?
Well, there is no pretty or easy answer to this question. We can put lipstick on the pig, but it still says oink. And the problem here is that whenever you migrate to a different backup application, you pretty much maroon all the data presently retained and catalogued by your existing backup application. (There are alternatives, but they are often very expensive, to the point where I have yet to see more than one or two customers out of hundreds be able to justify the process.)
So your data is marooned. The best thing is to encapsulate that TSM server in a VM and make a backup and turn it off.
And by the way, this answer isnt signficantly different no matter what backup application you choose. Generally, your data is bound to that app for the duration of the retention, and that is that.
What is better? Well, that is for the next post—why I recommend that there is a better way to do things, and my reasons for making this recommendation.