Tsm

Well, today we had a rather weird problem with our TS3500. TSM running on AIX basically went bonko and spit out weird media sense errors, all stating that there is a hardware or media error of unknown nature: 1 2 3 4 5 6 7 8 9 ANR8943E Hardware or media error on library LIB3584 (OP=00006C03, CC=-1, KEY=04, ASC=44, ASCQ=00, SENSE=70.00.04.00.00.00.00.46.00.00.00.00.44.00.00.00.00- .00.40.82.00.00.00.40.00.00.02.00.48.01.A1.00.00.00.00.0- 0.06.1B.00.01.09.00.00.00.00.00.00.00.00.00.00.00.00.00.- 00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00- .00.00.00.00.00., Description=An undetermined error has occurred). Refer to Appendix C in the 'Messages' manual for recommended action. ANR8381E LTO volume HG4480L4 could not be mounted in drive DR9 (/dev/rmt8). After restarting the TSM server (as in the service, not the whole box) five times, which didn’t resolve squat we decided to take a look at the TS3500 itself. We opened up the Management interface and tried moving a tape into a drive. That didn’t work. Hrmmmmm. ...

Well, for the past two months I had a case open with NetApp to figure out this SnapVault replication issue we were seeing. The initial transfer of the SnapVault relation would complete with a hick up, manual snapshot transfers also work - just the scheduled, auto-created Snapshots won’t replicate. At first I (and the NetApp support) thought this was an issue with SnapVault itself, however after being away for the last four weeks I looked at the issue with fresh eyes. After a short peek into the logs, I found what I had found back when I first looked into this. ...

Well, we’ve been trying to come up with a decent way to backup NetApp snapshots to tape (SnapMirror To Tape), so we evaluated all the available methods of using NDMP backups. There’s Image Backup in two different variants - FULL and DIFFerntial There’s SnapMirror To Tape So the Image Backup is one of the ways. However the DIFFerntial backup only works for CIFS and NFS shares (which we don’t use). We only have FC luns (or rather FCoE luns), so there’s only a single (or in case of the boot luns more than one) file in each volume. With that however, each run of the Image Backup with the DIFFerential option, it’s gonna backup the full size of the volume (plus the deduplicated amount). ...

Well, to save everyone else the trouble (since it isn’t documented anywhere - and I just spent about an hour finding the cause for this), if you need to configure NDMP on your NetApp Filer, make sure you also configure an interface other than e0M. Apparently the necessary controlport for NDMP (10000) is being blocked on e0M, thus ndmp may be configured and running, however TSM is gonna complain that it is unable to connect to the specified data mover. ...

Ran into another weird problem the other day … Had a few Windows boxens running out of space. Why ? Well, because TSM includes a System-State backup when creating the daily incremental. Now, apparently (as stated by the IBM support) it isn’t TSM’s job to keep track of the VSS snapshots but rather Windows’. Now by default, if you don’t click on the VSS properties of a Windows drive, there is no limit on the volume. Thus, VSS is slowly eating up all your space. ...

Today I’ve been fighting with Solaris 10 and the SMF Manifest (others would call it init-script …). Since I wanted to do it the proper way (I could have used a “old-style” init-script, but I didn’t wanna ..), I ended up combing the interweb for examples .. As it turns out, not even IBM has documented a way, on how to do this. In the end this is what I’ve come up with: ...

As the title says, I’ve been playing with vCB (inside a VM) and the TSM integration with newer (>6.0) clients for work. Result of all this work should be a feasibility study. We’re currently thinking about replacing our VMware server(s) with ESXi. But as most of you know, if you install ESXi, you simply can’t install anything (well, you can .. on ~100KB of disk space, which is compared to a TSM client weighing roughly 120MB nothing!). As we would like the possibility to backup VMs on image-level, I went looking at solutions. ...

We received a preinstalled customer server the other day, for which we had declared “as-is” support only, since it is running Lucid Lynx. Now today, I started getting the TSM client to work. Was kinda weird, since at first dsmc was reporting something like this: # ./dsmc: no such file or directory After fiddling with it a bit more, here are the control files, as well as the prerm and postinst-scripts for TIVSM-API, TIVSM-API64 and TIVSM-BA: ...

Today, I had a rather troublesome morning. Once I got to work, Nagios was already complaining about the lin_taped on one of our TSM servers, which apparently failed due to too many SCSI resets. Additionally, I can’t login using the VE console (I can login however using SSH) so I ended up opening up a IBM Electronic Service Call (ESC+). Using SSH, I can get some information on the VE’s status: ...

Well, after I finished my first OCF agent back in October 2008, we have it running in production now for about ten months. During that time, we found quite a few points in which we’d like to improve the behaviour with that Linux-HA should handle TSM. Shutdown TSM nicely if possible (Cancel client sessions, cancel running processes and dismount mounted volumes) Better error handling So, after another week of writing and testing with a small instance, I present the new OCF agent for Tivoli Storage Manager. It still has one or two weak points, but they are negligible. I still need to write the documentation for it, but the script should just work …