If you query the ADSM-L archives for "multi-session" and "collocation," you'll see the latter is definitely discussed more than the former -- way more.  Which is actually better for improving TSM restore speeds?  This blog entry attempts to discuss the pros and cons of both, as well as what you need to do to activate either one.

Collocation minimizes the number of tape volumes that a given client's data is written to, and it's activated on the storage pool level.  If the storage pool that you send a given client's backups to is collocated, then that client's backups will be collocated to the degree specified by that storage pool.  The greatest degree of collocation is filespace collocation, followed by client collocation, then (as of TSM 5.3) collocation groups.  The more you collocate, the fewer tape mounts will be required during restores.  Unfortunately, the more you collocate, the more you negatively impact your media utilization and the more tape mounts you will need during backups.

Multi-session restore allows you to use multiple tape drives during a single no query restore (NQR).  Since it can take several minutes for each tape to get mounted and positioned to the proper section of tape, using multiple tape drives can ensure that at least one tape drive (and potentially more) is always restoring data.  Of the three usual suspects (TSM, NetBackup, NetWorker), TSM is the only backup product with this feature.

If a set of backup files is completely collocated and fit on one tape, you will not be able to perform a multi-session restore.  (If all the backups are on the same tape, you can't mount multiple tapes.)  This is why the two are seen as competiting concepts.

I would urge you to do your own testing, but it would seem that several (you can use as many as 10) tape drives spinning simultaneously during a restore would be faster than a completely collocated tape.  Perhaps a good mix would be to combine multi-session restore with collocation groups.  That way, you limit the number of tapes that a given client may send it's backups to, but allow multiple tapes to get created so that a multi-session restore would work.

The one challenge of multi-session restore is that the values you set to enable a multi-session restore also activate multi-session backup, which would greatly increase the number of tape mounts you would need during backups.  Therefore, most people activate multi-session restores when they're about to issue a large restore.

To enable multi-session restore, follow the instructions in this checklist.

Comments

Add New Search

grammar - What about the legal question?   | Registered | 2007-07-12 17:19:50 I'm convinced that TSM is a technology win over either NetBackup of NetWorker, and have been for a few years. BUT What about the legal question? Many of the ways in which TSM is good technologically scare the pants, shoes, socks, and shorts off lawyers. The idea that it's simply impossible to provide an answer to the question, "On what volser is this data?" and have it be true until the data actually expires drops their mandibulae to the floor. I know how certain Large Financial Institutions deal with this (use NetBackup instead for systems about which Legal cares), and I know a few ways to ameliorate the effects (NetApp ne' Decru DataForts, for example), but does IBM have any functional ways of dealing with this Business Issue while still reaping the benefits of those features?

cpreston   | Super Administrator | 2007-07-13 09:57:57 In a multi-product site like backupcentral, your first sentence is tantamount to trolling. It's liable to start a flame war. So I'll move on to the other part of your post. You're answering a question with a question, are you? I'd say the answer to your question would be backup sets/instant archives on WORM media. When we're talking requests from legal, we're talking archives -- not backups. And I would say that TSM's way of putting something on a tape and having it stay there is a backup set. And if you put it on WORM media, it's not going anywhere. The good and bad thing about them is that they're not tracked by the TSM database. It allows you to keep many backup sets without impacting the database, but it also means you can use backup sets to do regular restores. That's not their purpose.

zark - Not necessarily competitive   | Registered | 2007-08-27 14:57:11 The two concepts (collocation and multi-session restore) do not need to be in competition with each other. IBM recommends when setting up collocation groups that you define them in such a way that all of a group's data does not fit on only one tape. Instead, define them so that a few tapes are used, so that multi-session restore can be used. They provide a nice set of perl scripts (undocumented, possibly) that makes it easy to define collocation groups for your existing nodes. For some reason, it is a common misconception that when using collocation, you need to allocate an entire tape for each node (or group). This is not true, as TSM will stack multiple nodes (or groups) on a tape if it needs to, and does a fair job of spreading this out. However, if you do this you need to make sure that the number of tapes in "filling" status (what I call "writable tapes" doesn't get too low. If it does, then collocation can break down. It's something to keep an eye on to detect before it gets out of hand. You can write a simple SQL query, or you can use one of the several monitoring tools that are available to monitor TSM. Regarding the legal discovery issue: One thing that you can do with TSM is to use the TSM System Storage Archive Manager (SSAM) product. This is a feature in TSM that allows you to protect all data in a TSM server. It effectly prevents a TSM administrator from inadvertently or intentionally deleting data outside of the defined retention criteria. Once you have this, you can export TSM data from a normal TSM server to an SSAM TSM server to protect it for legal discovery purposes. If you trust your TSM administrators, you can do the same thing with a regular TSM server (configured appropriately) and save the effort of implementing an SSAM server.

Only registered users can write comments!

Powered by !JoomlaComment 3.12

Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved.