Active Data Pool - What's The Point?

To go along with the ADP story I have moved this older post up for easy reference.

With the release of TSM 5.4 Tivoli has added the ability to create an active data storage pool to allow for faster restore times. We have been looking into using them at work when I stumbled upon this interesting factoid in the description of the active data pools limitations:

1. The server will not attempt to retrieve client files from an active-data pool during a point-in-time restore. Point-in-time restores require both active and inactive file versions. Active-data pools contain only active file versions. For optimal efficiency during point-in-time restores and to avoid switching between active-data pools and primary or copy storage pools, the server retrieves both active and inactive versions from the same storage pool and volumes.

So my question is why don't they allow the client to restore all the active data first then restore the inactive, or why didn't they implement a multi-session restore process when they added active data pools to the product, thereby speeding up the restore process? With the amount of P-I-T restores I do, this issue makes the whole active data pool useless not just for me but I'm sure for many of you.

TSM 6.1 Technical Overview Presentation

IBM gave a Technical Overview of TSM 6.1 today and I thought I would post the links to the presentation for everyone. To go to the IBM presentation page click here.

To replay the presentation you can click here.

Who Did What?

This weekend I had an issue with a backup failing on a client using LAN-Free. When checking the TSM actlog the error I kept seeing was:

ANR9999D (Session: 265500, Origin: OD0BG-UAX001-STA) mmsshr.c(3874): ThreadId<13> Unable to obtain model type for '/dev/rmt23', rc = 46(SESSION: 265500)

So I had a good idea that the client and TSM Storage Agent were having issues communicating. I knew this because I had seen this error before when the TSM client and TSM Storage Agent were not at the same release levels. Checking the TSM client I found it at 5.4.0.0 and the Storage Agent at 5.3.4.0. Turns out an admin upgraded the client without knowledge of the Storage Agent, causing the backup failures. This is an example of what can happen when someone tries elbow their way into another groups area without the knowledge to do it right.

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 www.tsmworks.com/download. We appreciate feedback from TSM experts out there.
Thanks!

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 5.4.1.0 and ZFS support was added with the 5.4.1.2 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?

LAN-Free Unknown Feature

My boss brought this article to my attention so I thought I would pass it on. It discusses an unknown or little discussed capability of LAN-Free to act as a "pass-thru" server for other clients. In other words a normal client can connect to TSM through the LAN-Free agent that resides on another server. Basically the Storage Agent becomes a dummy TSM server. This can be helpful when you have backups that need to go to tape directly but the network connection between the client and the TSM server is hurt by inadequate bandwidth between switches, or firewall issues. You can check the article out here. I remember seeing this discussed on ADSM.org before, but have never attempted to try it.

Texas Government Pulls Plug on IBM

Well if you get a chance check out this article on ZDnet. It looks like IBM is losing the Texas government account due to backup failures and lost data. Having previously worked for IBM what I would like to know is what is not being said. When IBM takes over an account on an outsourcing deal they have to assume the horrible practices already in place then do their best to convert to a better software/hardware solution and processes. For example when I was with IBM we had a remote site that was using Arcserve for their backups and had two weeks worth of tapes. A couple months into the contract they lost a server and needed to restore the data and guess what...they couldn't. The process in place was for them to rotate two weeks worth of tapes continually. The tapes were four to five years old and had never been tested. They found out after the fact that the tapes had gone bad some time in the past and they were pretty much out of luck. Is this IBM's fault? They took some of the blame even though IBM was only a couple months into the contract and the smaller remote sites were secondary in the process change timeline.

The Monring News did report the following:

In a Nov. 3 letter to the governor’s office, IBM acknowledges the company overreached by assuming responsibility for existing technological conditions that are inadequate, inconsistent and not sustainable.