Wednesday, January 14, 2009

ART: Restore Testing software for TSM

We have a new product that does something unusual.

ART (Automated Restore Testing for TSM) test-restores a random sample of files. And it does this for every node at your site, automatically, on a schedule.

We don't think anyone has ever done this kind of comprehensive restore testing before.

ART has uncovered problems at every customer site it has tested. The problems are usually operational, and often easy to fix.

If you'd like to give the free trial a whirl (it's full-featured but limited to 20% of your nodes), go to We appreciate feedback from TSM experts out there.

Wednesday, January 07, 2009

TSM & File System Support

First off I hope everyone had a good holiday season. Now that we can focus on work again I wanted to discuss a topic of file system types. I just had an incident where a Solaris server had ZFS used for some newer file systems. The admins had added them without consulting us, and we didn't catch it because TSM didn't even attempt to back them up. Our client level was and ZFS support was added with the update. Once I updated the client the file systems were backed up successfully and show the correct format. We did see one file system was returning a type of UNKNOWN and that should have alerted us, but we were not receiving errors or failures on the backup of the server in question.

So here is the question, how do you keep something like this from happening in the future as new, more bleeding edge file system types are added? Obviously you need to inform your Unix Admins to work with you whenever they add a newer file system type, but if they don't alert you, and TSM doesn't report failures, how would you know? It's bound to happen as the Linux community adds newer, more robust file system types. Other than stay as current as possible with my TSM client levels (which wont always be the fix) what would you suggest?