All content from the EMC World 2011 BRS Sessions is now online.
Below is a list of all the BRS sessions from EMC World 2011 with links directly to the content, which include PowerPoint and audio recordings of the sessions. Enjoy! If you want to see more in-depth descriptions of the content, as well as the level and duration of the content, please find an expanded version of EMC World 2011 BRS Content here.
I thought I was done with TSM. And just when you think you are out, they pull you back in.
Only in this case I am being pulled back in by some feedback from a colleague on my previous column. I didnt want to relegate his input to a comment where it wouldn't get adequate notice, so I am reproducing it here in full and unedited. Full credit for this goes to Mario Correia. Mario has some impeccable credentials as a TSM administrator and consultant, and worked with one of the most respected TSM services groups in the industry. Mario had some great feedback on how often to run TSM reclamation on a Data Domain device.
"You really hit all the points with TSM and DD but I disagree on the comment about more aggressive reclamation at the 20%-30% thresholds.
Typically, 50% is the magic number where you hit the point of diminishing returns. If a tape is 50% utilized, I can take two volumes and consolidate onto one. I still have a net gain of 1 volume. But, once I go beyond that point, I’m not really saving anything from a volume perspective plus I’m also working much harder to get that minimal savings. When you throw in the actual space savings post-dedupe, it’s even less.
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.
Today I have a couple of links for all of you interested in backup:
First, the launch of the "official" EMC Backup and Recovery Systems Division blog, The Backup Window. There is lots of great content up already, and I am really liking some of the thinking about the future stuff that Stephen Manley is posting.
Second, Chad has a really great and thought provoking post about the future of backup for VMware enviornments. Really great, and really interesting. Although there is still a really big problem to tackle: data consistency within applications.
And to add to Chad's comments, I can think of a few other things I would like to see:
Built in charge-back modeling. It is great to provide users with the ability to define their own backup and provision it, but it also has some dangers--like users that dont understand retaining everything forever entails some risks.
Built in policy boundaries. There should be a setting that defines what the limits of a user-defined policy are. In other words, don't let people shoot themselves in the foot. vCD should have settings that limit frequency and retention for backups.
What if modeling that shows resource impacts of changes to backup policy.
Critical parts of the vCD structures in a multi-tenancy environment should be automatically "pinned" to the backups of that tenant so that those backups are portable and self-defining.
I am sure there are others--but it is great stuff to think about. Make no mistake, this is where backup is heading, in my opinion.
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!)
I have been spending a lot of time with TSM accounts lately, so I thought I would take the opportunity to discuss some of the gotchas and lessons learned from these environments, as they moved from a tape-centric backup environment to a disk based backup environment using EMC Data Domain technology.
The first and major thing each of these customers have realized is the incredible impact the Data Domain systems have on the schedule that TSM operates under. TSM is architected a bit different (understatement of the year) than most other backup products. And for a lot of reasons, the TSM server is usually busy 24 hours a day. In fact, it is almost always the case that it could be busy for more than 24 hours a day, but there just isn't enough time and resources to enable it to do everything it wants and needs to do.
The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC nor does it constitute any official communication of EMC.
