Tivoli Blog

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Team Blogs
    Team Blogs Find your favorite team blogs here.

TSM4VE control files (CTL) in a LAN-free enabled environment

Posted by on in Storage Management
  • Font size: Larger Smaller
  • Hits: 217
  • Subscribe to this entry
  • Print

The following is post is a guest-post written by Julien Sauvanet. I worked with Julien in the past, and asked him to write a guest post because I think it might be beneficial to the intended audience. The only thing I did was some moderation.

First of all, let’s explain what these CTL files are. When performing a virtual machine backup using TSM4VE, two different pieces of information (seen as files within TSM server database) are sent to the TSM server:

.DAT files: are basically the files containing the client’s data being backed up; .CTL files: these are the control files containing information about each DAT file. Each time a .DAT file is sent, there is a .CTL file associated to it, which is stored on the TSM server as well.


In short, the TSM4VE CTL files are the metadata needed for the TSM4VE backups. The CTL files are read from the TSM server when doing either a regular incremental VM backup or any recovery operation (e.g. full VM recovery, instant VM recovery, file level recovery). Note that during a backup operation, the CTL files are needed and are read (or restored). This is the reason why it is recommended to have these CTL files on a fast media (e.g. DISK storage pool).

As you are all well prepared TSM administrators or consultants, you obviously have planned to protect any files that are stored on your storage pools, including those .DAT and .CTL files. Let’s focus on the CTL files here. If your plan is to copy your data on disk (your COPYPOOL is disk-based) – you’re already done. But if you’re planning to protect your .CTL files on a tape-based COPYPOOL (for future vaulting purposes, for instance) you might run into trouble under some specific conditions.

If your datamover is hosted on a physical vBS machine (with LAN-free backup/restore path enabled), and if that same datamover has access to the tape copy pool through this LAN-free path, the .CTL files are read from the COPYPOOL tapes and the disk-based primary storage pool is skipped!

This is not a bug but a consequence of the LAN-free determination algorithm. As LAN-free is (or maybe was in the time this algorithm was coded) considered to be better than a regular LAN-based path, the datamover’s client session will mount the copypool tape and read the .CTL files through the SAN…That’s not a good thing, and as you can imagine performance might suffer.

I can see at least two ways to avoid this situation:

Place your COPYPOOL on dedicated library/tape drive environment, which is not accessible via the Storage Agent (use the VALIDATE LANFREE command to check that); Once the copy is done using backup stgpool, use the DRM command to move (or simulate the move) the tape(s) to vault or similar. The idea behind this, is to flag the tape as unavailable – so TSM won’t try to use it and use the disk volumes instead to retrieve CTL information.

This is documented in the following IBM Technote:

—- Julien Sauvanet

Comments are not available for public users. Please login first to view / add comments.