The usual IT babble
Posts tagged Tivoli Storage Manager
Tivoli Storage Manager Server 5.5.3
Aug 28th
I spent yesterday afternoon upgrading our TS7530, and in my fad I also upgraded TSM to 5.5.3. Now, once I started TSM it quickly started complaining about the paths to the drives.
ANR8873E The path from source TSM1 to destination VTL1_DR03
(/dev/lin_tape/IBMtape03) is taken offline.
ANR8873E The path from source TSM1 to destination VTL1_DR03
(/dev/lin_tape/IBMtape03) is taken offline.
HBA_LoadLibrary: previously unfreed libraries exist, call HBA_FreeLibrary().
ANR8873E The path from source TSM1 to destination VTL1_DR07
(/dev/lin_tape/IBMtape07) is taken offline.
ANR8873E The path from source TSM1 to destination VTL1_DR07
(/dev/lin_tape/IBMtape-07) is taken offline.
I thought maybe this is a mere device problem (we have had them before), so I rebooted the boxes. But still no luck and I went home after about an hour of trying without any luck. In the morning, my co-worker called our trustworthy IBM service partner, and the TSM consultant said he had the exact, same problem yesterday. We would have two options:
- Enable the option SANDISCOVERY, with the (completely undocumented) Passive setting (setopt SANDISCOVERY PASSIVE)
- Downgrade back to 5.5.2
For now, we implemented the first option, in the hope that’ll solve our troubles. And it actually does.
Mass-updating Tivoli Storage Manager drive status
Aug 28th
I was fighting with our VTL again, and TSM was thinking all the drives were offline. In order to update the drive status, you’d need to go into the ISC and select each drive and set them to ONLINE. Since I’m a bit click-lazy, I wrote a simple nested for-loop, which gives me the output to update all the drives at once:
for i in 1 2; do
for k in $( seq -w 1 32 ); do
echo "UPDATE DRIVE VTL$i VTL${i}_DR${k} ONLINE=YES"
done
done
Result is a list like this:
... UPDATE DRIVE VTL1 VTL1_DR31 ONLINE=YES UPDATE DRIVE VTL1 VTL1_DR32 ONLINE=YES UPDATE DRIVE VTL2 VTL2_DR01 ONLINE=YES UPDATE DRIVE VTL2 VTL2_DR02 ONLINE=YES UPDATE DRIVE VTL2 VTL2_DR03 ONLINE=YES ...
The same goes for mass-updating the path status:
for i in 1 2; do
for k in $( seq -w 1 32 ); do
echo "UPDATE PATH TSM$i VTL${i}_DR${k} SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL$i ONLINE=YES"
done
done
Result is a list like this:
... UPDATE PATH TSM1 VTL1_DR31 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 ONLINE=YES UPDATE PATH TSM1 VTL1_DR32 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 ONLINE=YES UPDATE PATH TSM2 VTL2_DR01 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL2 ONLINE=YES UPDATE PATH TSM2 VTL2_DR02 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL2 ONLINE=YES
TSM: Restoring the database/recovery log to a point-in-time
Apr 24th
Well, my co-worker just called on my cell (it’s Friday, 16:00), and asked me which start-up script he needed to change in order to restore the database. My first response was, “ummm, that’s gonna be hard, we’re using heartbeat”.
Okay, so after a bit of asking I got out of him what he wanted to achieve by changing the start-up script. Apparently he did something to crash Tivoli Storage Manager (or rather repeatedly crash it) and wanted to restore the database. He talked to one of the systems partner we do have (and I’m happy we have them most of the time), who in return told him how to do it, but forgot a minute after he hung up the phone.
So, I went digging while he still was telling me how he got Tivoli to kick his own ass … After a bit, I thought “hrrrrrm, shouldn’t this be covered in the Tivoli documentation ?”, and surprisingly it’s actually covered in the documentation.
It’s actually rather simple.
- Stop the dsmserv Linux-HA cluster service (tsm-control ha stop tsm1)
- Setup the environment (since we’re running multiple instances of Tivoli Storage Manager – export DSMSERV_DIR, export DSMSERV_CONFIG)
- Enter the path of the server
- Run dsmserv restore db
- Wait some time (took about half an hour to restore the 95G database and the 10G recovery log)
- Start the dsmserv Linux-HA cluster service (tsm-control ha start tsm1)
- Update the server-to-server communication, since the restore db changes the communication verification token
> tsm-control ha stop tsm1
- tsm1 (dsmserv) -> ha: [ OK ]
> export DSMSERV_DIR=/opt/tivoli/tsm/server/bin
> export DSMSERV_CONFIG=/opt/tivoli/tsm/server/tsm1/dsmserv.opt
> cd /opt/tivoli/tsm/server/tsm1
> /opt/tivoli/tsm/server/bin/dsmserv restore db todate=TODAY totime=08:00:00 source=dbbackup preview=no
.... wait some time ....
> tsm-control ha start tsm1
- tsm1 (dsmserv) -> ha: [ OK ]
TSM client: Backing up files with umlauts on SLES
Mar 2nd
In the past, I always had problems with SLES and our Tivoli Storage Manager client’s when backing up files with german umlauts. Well, today I looked a bit harder, and quite quickly found a solution.
sles9 root [0] > env | grep ^LC LC_CTYPE=de_DE.UTF-8
As you can see from the above, SLES9/10 ain’t setting LANG or LC_ALL (which I searched for first), but is setting LC_CTYPE.
So, simply changing the LC_CTYPE in the init-script and/or prepending the dsmc command line with a new LC_CTYPE fixes my umlauts problems!
sles9 root [0] > LC_CTYPE="en_US" dsmc incr
Well, I had a long’ish talk with one of my trustworthy IBM senior consultants the day after writing this …
He told me something along the lines of this:
If you would like to back up files with names containing characters with a code > 127 please ensure that you have chosen a SBCS character set for your locale. The default code page C or the code page POSIX supports characters up to 127 only. Files whose names contain special characters will be skipped if C or POSIX is used. It is strongly recommended to perform a system backup by using a SBCS character set to prevent any file or directory from being skipped. This behavior for different locales is intended.
And this:
The UTF-8 locale is default on some Linux platforms. However, TSM Client currently does not support running under UTF-8 locales (such as en_US.UTF-8 and ja_JP.UTF-8). Export your LANG and LC_ALL environment variables to the iso8859-1 or EUC versions of your locale and then start a new xterm (or mlterm) session prior to running TSM Client.
That basically means, at least for using the TSM Client Java Interface (dsmj) and the scheduler/client acceptor daemon you have to switch your locales to something _not_ UTF-8 capable.
He also mentioned, that IBM doesn’t have a real solution for this problem, as well that there is no real workaround. You need to invest some time into figuring out the “right” locale setting for your system(s), since after writing the above I came to the result that it ain’t enough ..
You need to do the following:
lang="de_DE@euro" export LC_CTYPE="$lang" export LANG="$lang" export LC_ALL="$lang"
After doing so, the scheduler and the command-line client works …
Updating path information for TSM
Jan 28th
As I did some switching today (between the new lin_tape version by IBM and our own lin_tape version), I ended up writing those lines a dozen times. Here is (just for me, if you don’t care .. skip ahead) on how to generate a list of commands:
for i in $( seq -w 1 32 ); do
token="${i/0/}"
path_prefix="/dev/lt/IBMtape12245775"
echo "DELETE PATH TSM1 VTL1_DR$i SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1"
echo "DEFINE PATH TSM1 VTL1_DR$i SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 DEVICE=$path_prefix$((token+11))A1"
done
which should get you a list like this:
...
DELETE PATH TSM1 VTL1_DR21 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1
DEFINE PATH TSM1 VTL1_DR21 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 DEVICE=/dev/lt/IBMtape1224577532A1
...