I ran into an interesting problem recently. A de-duplicated pool containing TDP for Oracle backups was consuming much more space than would otherwise be indicated. Here’s what the occupancy looked like:

Node Name         Storage         Number of     Logical
                  Pool Name           Files     Space
                                                Occupied
                                                (MB)
----------        ----------    -----------    ----------- 
CERN_ORA_ADMIN    CERNERDISK            810      31,600.95 
CERN_ORA_BUILD    CERNERDISK          1,189      74,594.84 
CERN_ORA_CERT     CERNERDISK            402   3,876,363.50 
CERN_ORA_TEST     CERNERDISK            905   7,658,362.00
LAW_ORA_PROD      CERNERDISK          1,424     544,896.19 
OEM_ORA_RAM       CERNERDISK          2,186     524,795.31

That works out to about 12.7 TB. And, here’s what the storage usage looked like:

The client OS level field in TSM for most operating systems is pretty straightforward. On Linux, it’s the kernel version, HP-UX and AIX show a recognizable OS level. For windows the OS level is more cryptic. Here is a list of the OS levels:

UPDATE: I got some feedback that some people are not clear on creating multiple schedulers, so I’m updating this post.

Since I wrote about doing TSM Full-VM Image Backups With VStore API I’ve done more testing, and have put it into “production” with our smaller VMWare cluster. This cluster is managed by one department inside IT. It has some VMs used by customers inside the enterprise, some VMs used for development or testing, and some VMs used by the group inside IS. Now that I’m ready to put VMWare backups into practice, I need to schedule the backups. And, I got some great feedback on the first post, so I thought I would follow it up.

DRAFT – I’m still working on it

In TSM 5.4+, there is an option for backup encryption. Unlike SSL encryption, the data is stored on the server in an encrypted format. So, your tapes are finally, really, secure. Without paying for encryption capable libraries and drives. I always thought it was kind of lame of IBM to say that the TSM backup takes are useless without the TSM database. It looks to me like the data is in the clear on the tape, there’s no reason you couldn’t read the whole tape into a huge file and text search it if you really wanted it bad enough.

I haven’t looked at TSM backup encryption before, even though it’s been in TSM since version 5.4 (maybe earlier). But, if you think about it, there isn’t any data MORE important than your backup data. Data that is usually encrypted on the wire, is most likely sent in the clear by the TSM client. There are a couple of ways to slice this, but I started with the SSL encryption feature. There is a client encryption option in TSM 6.1 (possibly earlier) that encrypts the data with an encryption passphrase, but that has more issues and isn’t very compatible with server-side de-duplication.

If your wondering who is restoring files, and what they’re restoring, you can capture that information to a custom log file. It’s a pain to get the same kind of data out of the activity log, but you can dump it to a “formatted” text file. You can send it to a user defined script or program too. The offending codes we’re looking at are ANR0503 and ANR0504.

First, we need some options added to our dsmserv.opt file:

These are various server SHow commands I’ve picked up from various sources. This is definitely not an exhaustive list, and these commands are added and dropped from TSM based on the version, these commands are not supported and may not work for you.

SHow ASQUEUED:
If you have a client session or process stuck, it may be waiting for a drive. You can use this command to see if there are sessions queued waiting for mount points.

SHow ASVOL:
If you are having problems with sessions or processes queued, or waiting for tape volumes, then this command will display the in-memory list of assigned volumes.