Wednesday, May 31, 2006
All Hail The Java GUI!
Interesting resolution to a restore I just had thought I would pass it on... On one of our Win2K3 servers all admin accounts were crippled due to some corruption in the registry (my vote was on Gremlins!). So they wanted to restore the system state to a week ago. I tried and the client core dumped due to our permissions being crippled. So I tried one other thing and that is the Java GUI. I figured since it runs under the System Account it might work. Well it did and fixed their problems....I had not used the Java GUI in ages but here is one situation where it came in quite handy.
Tuesday, May 23, 2006
LAN-Free In A Shared Library Environment
I had to setup a LAN-Free client recently and ran into some trouble with the tape environment. As you all know I use a shared library environment where multiple TSM servers share a single large library through a library controller TSM instance. This works great since it allows for a shared scratch pool and TSM can be bounced faster since the DB is less than 2GB. The problem arises when trying to setup a LAN-Free agent in this complex environment. If you have ever read the directions for LAN-Free you’ll notice they can be quite confusing since they switch the client port to 1502 to accommodate the LAN-Free agent’s default of 1500. Now understand 1500 makes sense because the LAN-Free agent is really just a stripped down TSM server. Since the TSM server uses 1500 by default so does the agent. I decided to use port 1502 for the agent but forgot to change it in the dsmsta.opt file. This kept me from being able to connect to the agent from the client since it was looking at port 1502 and the agent was still using port 1500.
Another issue the directions don’t fully explain is where to point the LAN-Free agent when setting it up. I will explain how here and hopefully make it easy to understand.
1. Setup the dsm.sys client file with the following lines
ENABLELANFREE YES
LANFREECOMMMethod TCPIP
LANFREETCPServeraddress <loopback, DNS name, or IP>
LANFREETCPPort 1502
2. Define the agent to the node’s TSM server and the library controller as a server
define server storagent serverpassword=passw0rd hladdress=<loopback, DNS name, or IP> lladdress=1502
Also don’t forget to register the node if not registered already.
register node <nodename> <password> domain=<domain name>
3. On the TSM library controller instance path the drives seen by the node/LAN-Free agent machine. I am assuming you have connected the client node to the SAN environment and zoned a number of drives to the node. When seen in the OS you can define the path. Make sure you map the paths correctly. In AIX this can be done by running the lscfg –vp | more command and noting the drive serials and noting them to their corresponding drive in TSM.
DEFine PATH STORAGENT <Drive Name> SRCType=SERVER AUTODetect=YES DESTType=DRIVE LIBRary=<Library Name> DEVIce=/dev/rmtX ONLine=YES
Note: For ACSLS libraries more configuration parameters need to be set. I am showing an IBM hardware example since I would never use anything else!
4. On the client node go to the storage agent’s folder and update the dsmsta.opt file with the following
tcpport 1502
5. Now from that storage agent directory run the following command
dsmsta setstorageserver myname=storagent mypassword=passw0rd myhladdress=<loopback,DNS name, or IP> servername=<node’s tsm server IP or DNS name> lladdress=1500 <or port used by node’s tsm server>
Note: Notice I am pointing the agent to the node’s TSM server. Even though it is a library client and does not control the drives, by defining the agent to both the client TSM server and the controller instance a handoff from the library client to the library controller will occur automatically. If you do not define the LAN-Free agent to the library controller the agent will fail.
You should now be able to test the configuration by starting the dsmsta in the foreground and then from another telnet window start a TSM command line client and run a backup(if using Windows open a dsmc client). If setup correctly you’ll see the agent contact the controller for a drive and mount a tape and commence a LAN-Free backup.
Another issue the directions don’t fully explain is where to point the LAN-Free agent when setting it up. I will explain how here and hopefully make it easy to understand.
1. Setup the dsm.sys client file with the following lines
ENABLELANFREE YES
LANFREECOMMMethod TCPIP
LANFREETCPServeraddress <loopback, DNS name, or IP>
LANFREETCPPort 1502
2. Define the agent to the node’s TSM server and the library controller as a server
define server storagent serverpassword=passw0rd hladdress=<loopback, DNS name, or IP> lladdress=1502
Also don’t forget to register the node if not registered already.
register node <nodename> <password> domain=<domain name>
3. On the TSM library controller instance path the drives seen by the node/LAN-Free agent machine. I am assuming you have connected the client node to the SAN environment and zoned a number of drives to the node. When seen in the OS you can define the path. Make sure you map the paths correctly. In AIX this can be done by running the lscfg –vp | more command and noting the drive serials and noting them to their corresponding drive in TSM.
DEFine PATH STORAGENT <Drive Name> SRCType=SERVER AUTODetect=YES DESTType=DRIVE LIBRary=<Library Name> DEVIce=/dev/rmtX ONLine=YES
Note: For ACSLS libraries more configuration parameters need to be set. I am showing an IBM hardware example since I would never use anything else!
4. On the client node go to the storage agent’s folder and update the dsmsta.opt file with the following
tcpport 1502
5. Now from that storage agent directory run the following command
dsmsta setstorageserver myname=storagent mypassword=passw0rd myhladdress=<loopback,DNS name, or IP> servername=<node’s tsm server IP or DNS name> lladdress=1500 <or port used by node’s tsm server>
Note: Notice I am pointing the agent to the node’s TSM server. Even though it is a library client and does not control the drives, by defining the agent to both the client TSM server and the controller instance a handoff from the library client to the library controller will occur automatically. If you do not define the LAN-Free agent to the library controller the agent will fail.
You should now be able to test the configuration by starting the dsmsta in the foreground and then from another telnet window start a TSM command line client and run a backup(if using Windows open a dsmc client). If setup correctly you’ll see the agent contact the controller for a drive and mount a tape and commence a LAN-Free backup.
Monday, May 8, 2006
TSM 5.2 End Of Service
I just received notification on end of service for TSM 5.2. The date given was April 30, 2007. So I would advise everyone to plan their upgrades to 5.3 or higher accordingly. For more information check out the IBM End Of Service webpage.
Thursday, May 4, 2006
UPDATE on NDMP Problem!
Support has identified the NDMP problem exists in TSM 5.3.3 if the ONTAP version is lower than 7.1. If you have NetApps make sure your ONTAP version is at or higher than version 7.1 before you upgrade your TSM server to 5.3.3 or higher.
Wednesday, May 3, 2006
TSM 5.3.3 NDMP Issue!
We discovered a problem with TSM 5.3.3 and failed NDMP backups. It seemed to be occurring on large volumes. After investigating the issue support was called and through further investigation it was discovered that there is a bug in the implementation of TSM’s use of the NMDP 4 protocol. This bug will cause some NDMP backups to fail when the backup spans volumes (i.e. uses more than one tape to do the backup of the volume). The suggestion is to either stay at version 5.3.2 or to use the following option in the dsmserv.opt file:
(Note: there is no problem with data integrity of backups that show completed)
FORCENDMPVERSION3 YES
This option will use the older NDMP protocol and should resolve the failures until a fix is released.
(Note: there is no problem with data integrity of backups that show completed)
FORCENDMPVERSION3 YES
This option will use the older NDMP protocol and should resolve the failures until a fix is released.
Thursday, April 27, 2006
Interesting Command Update In TSM
I found this interesting update on the Tivoli website about the enhancements to the DISABLE/ENABLE SESSIONS command. Basically it discusses the change to the commands in TSM 5.3.1.0 and how the command now disables sessions not only for client sessions, but admin and server-to-server sessions also. This would not be problem had a customer not revoked system authority from his SERVER_CONSOLE ID. This locked the customer out of his server entirely and his only recourse was to either rollback to 5.3.0 or to restore a DB Backup from before the disable was issued. Have many of you revoked SERVER_CONSOLE privileges? I never would consider it since it is a fail-safe in the event something bad happens. I understand security but if the person can get onto the server and start the program in the foreground you have bigger problems than the SERVER_CONSOLE ID having system authority.
Thursday, April 13, 2006
TSM Is Not A Security Tool!
I thought I would pass along some of the crazier things I have seen with TSM and get your input to see who has the wildest/stupidest story concerning TSM. My most recent experience is when I was ask to setup scripts to alert security personnel when a specific file was changed and backed up. Reason? If the file was changed it showed that the servers had been compromised. I, of course, stated without reservation NO! TSM is not a security tool and will not be used as one. That’s what security-monitoring tools are for! Then there was the time we were asked to provide a hard copy list of every file in backup storage. (That means a printed list of every file on tape. I kid you not!) This insane request was from a customer who had no idea what they were asking. When told what the results would be they insisted on having the list provided. We were floored, what idiot is going to sift through the mounds of paper and identify every file? Of course there is always the requests that come in from people wanting data from the 70’s, 80’s, and a lot from the 90’s. If I had a REEL to REEL machine or older tape hardware, I still wouldn’t have the foggiest idea how to restore the data since the computers the data was from are long gone and what tools were used to backup the data are probably buried with the person who once used those archaic tools (You mainframe people crack me up!). Have you ever seen Real Genius? If you haven’t then I suggest it for a good laugh. There is one character in particular that I love, Lazlo Hollyfeld. Played by Jon Gries, Lazlo is a scientist at a MIT/CIT like school that lives in the closet of the dorm room of the lead characters who suffered from a breakdown and is not quit living in reality. I work with a Lazlo! I swear he looks like Lazlo and when he goes into his cube it reminds me of him. I say this because he is a “Mainframer” and laughs and scoffs at us Open Systems people. Even he didn’t have a clue how data from that long ago could be restored since none of the software or hardware was available. Then there are always the requests where the person needs data restored that is missing. What data? They are not sure! What was the name or do they know some portion of the name or extension? No! How long has it been gone? Not sure! They think it was from 4-5 years ago. These requests kill me! Even if I was willing to go look at the old archives of the systems I still wouldn’t have any idea what the customer was really looking for. These are just some of the things I have run into and I am sure you all have many more great stories! Please share and let others feel your pain and enjoy a good laugh.
Subscribe to:
Posts (Atom)