AIX Image Backup Performance Issue

I am running 3 simultaneous image backup jobs on an AIX server and the HBA only shows 20% utilized and my throughput sucks. I am using -imagetype=static and the FS's in questions are EMC clones split off and remounted to a new server. When I have done image backups before they were wicked fast...now not so much. Any ideas what I might have missed? I have an ACSLS STK 8500 with LTO-3 drives. Even over gig-ether I've seen better performance. We did check the CPU and memory usage and they are fine. Lots of I/O wait, not sure why I would see that with statc image backups.

TSM facebook Group

If you're on facebook and would like to network with other TSM admins check out the new TSM group. It's currently looking to grow and can allow us all to network for information, jobs, tips, and just getting to know each other. Thanks to Henrik Wils for creating it!

EMC Backup Advisor

I am currently working a project to install and setup EMC Backup Advisor in our environment. If anyone has experience with the product I'd like to hear your thoughts and opinions. So far it seems like it can monitor almost anything. Hopefully it doesn't become such a huge/complex tool that we'll spend half our time trying to manage it.

Layout Issue

For anyone who liked the Table Of Contents feature, I have had to temporarily remove it because the javascript was not playing nice with IE or Firefox (at least not on my system). The only browser that handled it correctly was Google Chrome. I hope to have it back soon, I liked the feature.

The BACKUP VM command is not supported on this client (ANS1184W)

Just a heads up, so others don't run into this - TSM Integration w/VCB is not supported on x64.
As per this posting to ADSM-L by Andy many months ago:

At the time 5.5 VCB support was being developed, the 64-bit VMware VCB framework was not available (though I think one has since been introduced). So TSM support is currently 32-bit Windows 2003.

Good news is that 'backup vm' works on the x64 platform when using the x32 client.

x64 binaries - v5.5.1.0 - C:\progra~1\tivoli\tsm\baclient
x32 binaries - v5.5.1.0 - C:\progra~1\tivoli\tsm\baclient32

C:\progra~1\tivoli\tsm\baclient32.dsmc.exe backup vm -vmlist="fileserver[fileserver_fs]"

Storage Agent Device Issue

So one of my co-workers was tasked with figuring out why a drive was shown in TSM as being assigned to a storage agent when the storage agent was not actually using it (we had even restarted the agent and the library controller still showed the agent as owner of the drive). As it turns out there is an issue with down level TSM device drivers being used between an AIX TSM server and Windows Storage agents. You can find the APAR here. Here is a brief rundown of the problem.

After a review with the Windows and AIX Device Driver development team, it was determined that one of the Windows STA's placed a persistent registration on a drive, failed the persistent reservation, and then failed to release the registration during the recovery path. The registration causes a problem for AIX but not Windows due to the differences in SCSI 2 and SCSI 3 used by Windows and AIX. This hasbeen fixed and the recommendation was to upgrade to the current Windows Device Driver - 6.1.9.3. If you are not at 6.1.9.3 or higher, this is most likely your causing your problem.

You can download the latest driver from here:

ftp://ftp.software.ibm.com/storage/devdrvr/Windows/

Here is the tsm apar I mentioned:

http://www-01.ibm.com/support/entdocview.wss?uid=swg1IC57753&NotUpdateReferer=

Defaults should never be trusted

I've performed a few audits recently and this one keeps popping up, again and again!

Please be aware that the defaults provided when defining a new storage pool will turn on collocation by GROUP. If this default is specified and no collocation groups are defined then the TSM server will collocate data by NODE!

Pleasant little surprise eh?

COLlocate
Specifies whether the server attempts to keep data belonging to a single client node, group of client nodes, or client file space stored on as few volumes as possible. This parameter is optional. The default value is GROUP.

If you specify COLLOCATE=GROUP but do not define any collocation groups or if you specify COLLOCATE=GROUP but do not add nodes to a collocation group, data is collocated by node.

It never hurts to double check everything, here's some queries I use all the time to sanity check collocation: (replace the stgpool_name as needed)

• select stgpool_name, access, collocate, maxscratch, reusedelay from stgpools
• select count(distinct node_name) as "Number of Nodes", volume_name from volumeusage where stgpool_name='%_TAPE' group by volume_name order by "Number of Nodes" desc
• select count(distinct volume_name) as "Number of Tapes", node_name from volumeusage where stgpool_name='%_TAPE' group by node_name, stgpool_name order by "Number of Tapes" desc
• select count(distinct volume_name) as "Number of Tapes", node_name, stgpool_name from volumeusage group by node_name, stgpool_name order by "Number of Tapes" desc