Wednesday, June 20, 2007

NDMP Question

I have a customer who wants to have a copy of a NetApp volume. That's not a problem but my question is this, is an NDMP dump initiated by TSM capable of being restored without a TSM server? Since TSM labeled the tape is there any issue with trying to restore the data directly from a NetApp with a direct attached drive? Also when running an NDMP dump directly from the NetApp and not from TSM is the TOC/Catalogue stored on the same tape with the data? My thinking is that the NDMP dump even though initiated by TSM is still just an NDMP dump. My concern is the TSM labeling and if it would cause any readability issues for a NetApp based restore?


I contacted Tivoli support and a NDMP backup is fully independent of TSM. I figured it was but wanted to make sure. The customer wanted us to backup a NetApp volume and send him the tape to hold indefinitely. Now I know I can just send him one of the older NetApp backups from the time period requested without needing to do anything special.

Tuesday, June 19, 2007

Restoring Windows Shares

This is a repost from June 2005

Well, it inevitably happens that a large fileserver is being replaced, goes down, or goes bad and you have to restore it. Well if you are restoring to the same type of hardware then life is beautiful and NT/2000/2003 has no problems and acts like the good little boy it should be, but what happens when you have to restore to new hardware, or are refreshing the server to a newer more powerful server? This is when NT can be worse than that bratty little kid I wanted to strangle in the movie Problem Child. Personally John Ritter should have shot him and buried him in the back yard, but I digress. So how can you restore Shares or any other piece of the registry with TSM when NT doesn't like having the registry of another machine of different hardware restored? Well that's were a little ingenuity and some preemptive strategy comes in handy. The easiest way is to setup a script using the command line registry tool REG.EXE that runs a REG EXPORT KEYNAME each day and stores it as a file. Here is the string needed to backup the Shares key. (The following is all one line)

REG EXPORT HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares C:\BACKUP\SHARESEXP.TXT

The command backs up the Shares key to a folder I created on the C: drive called Backup, but you can put it wherever you like. A simple batch file will suffice to execute the export and you can either schedule it through Windows daily or through TSM. Yes, you can do that and TSM will gladly back it up. This allows you to then restore the export file and reimport it into the server of choice. Just make sure that with any schedule where you are executing a command/batch file you put the full path of the file or else TSM can possibly fail to execute it, even if its in the TSM BACLIENT directory.

Ok, not everyone has that process in place and needs to restore the Share key now! Well have no fear TSM can help you accomplish it. Let's look at the process for this situation and I'll provide some links. First off you can restore the registry without activating it. The command to do so is



Now for each process you can restore specific keys but for ease of use the entire restore will work. TSM will restore the registery to the c:\adsm.sys\computername\ directory. From this point you can load the hive in RegEdit containing the share key and export it to a file. Once exported you should be able to import it into the current registry thereby restoring the shares. Here is a Microsoft document that covers loading the hive and processes to use. There is also a good document on backing up and restoring the registry here. If you have any questions feal free to comment and I'll respond as soon as possible.

Monday, June 18, 2007

Oracle RMAN Catalogue Cleanup

This is an update to a story posted back in August 2005

Why do people love Oracle? When I hear mention of Oracle I think of Luke Skywalker when he saw the Millennium Falcon, "What a piece of junk!" Like the Falcon it looks clunky, breaks down easily, and has the most temperamental behavior. When it's running, however, it screams. The problem is that DBA's and/or the RMAN catalogue sometimes don't do appropriate cleanup. If the DBA's are doing their job they should be using the tdposync syncdb command to do cleanup with TSM. If you cannot get them to do this or it doesn't seem to be working correctly you can use a manual process on the TSM side. If you want to make sure that a particular node is performing cleanup within TSM run the following select command -

select object_id from backups where node_name=[TDP NODENAME] and
backup_date < '2007-06-01 00:00:00'

This can be redirected to a file then used later to delete with an undocumented delete command. If there is data going further back than your retention requirements state then you have a problem with the DB cleanup.

I am posting the undocumented TSM individual backup object delete command here, but remember any deletion from the TSM DB is done AT YOUR OWN RISK!

delete object 0 [Object ID Number]

It's unsupported because Tivoli doesn't trust you to not screw stuff up, and although I don't think you will, I understand their concern. Put this into a shell script and you can process thousands of objects and do a large amount of cleanup in a short ammount of time.

Monday, June 04, 2007


We face a lot of problems recently with LAN-FREE on MS Windows platform. The TSM server runs on AIX or HP-UX, but the client is always MS Windows. Sometimes we lose one or a few drives, sometimes all of them. The problem doesn't evolve immediately only after a while. For these problematic customers we use J1A, E05 or LTO3 drives with the newest firmwares and drivers, of course.

Does anyone else have the same CHALLENGE?

Friday, June 01, 2007

When Good Libraries Go Bad!

This title might sound like a FOX network show, but the other day our SUN/STK Powderhorn library stopped mounting tapes and was giving us all sorts of problems. I called out SUN support and the service reps looked over the library and found nothing wrong. The next place to look was, of course, ACSLS. We cycled ACSLS twice and each time the library had trouble coming back online and even when we got the acs and and ports online we could not get the lsm to come online. Every attempt failed and I left the problem in the hands of our oncall to figure out with STK. When I finally heard from him I was told the problem was a duplicate IP had caused the whole library to become inaccessible to the ACSLS host. So this relatively simple mistake took out a backup and restore environment for most of a day. Just shows you can never plan enough for the types of problems that can occur.