I would have to agree that the export node is probably the best overall method.
Negatives: Tape requirements would grow at a huge factor. There is no commingling of systems. Even if you have servers with an archive name and a backup name each name would have to be exported separately. They can take a very long time, per server, depends on collocation number of files, number of versions... I exported a node with 650GB of DB backups around 35 files. It took almost 48 hours. Also: It might be wise to either lease or buy an additional jukebox... granted it maybe expensive but your company can't shutdown even if there is a government audit. Then create a new storage pool and do all your exports to that. It would allow you to do more than one or two exports at a time and allow you to complete your normal processing of backups. Wanda... or anyone... one question. When changing retention settings for a management class, are they immediately processed by TSM or does the next backup have to run to rebind all the files to the new class settings ? If it is the latter, the files that no longer exist on the client, but are still being retained, will not be rebound... They will stay with the same retention settings, right ? Duane Ochs Systems Administration Quad/Graphics Inc. 414.566.2375 -----Original Message----- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 15, 2002 3:09 PM To: [EMAIL PROTECTED] Subject: Re: Eternal Data retention brainstorming..... Well, this is an interesting "what-if" scenario for discussion! I'll take a crack at it... 1) Painful, but may be the best solution overall. 2) I don't think that will work. Turning off EXPIRE INVENTORY will prevent your tapes from reclaiming, but if you have a mgmt class set to 5 versions, I think the 6th backup will still make the 1st version invisible to the client. Test it and see. 3) Doesn't exist. 4) I think that would work. 5) I guess that would work, but what would be accomplished by using the new domains? Result is the same (I think) as just setting the existing management classes in the existing domains to never expire/unlimited versions. And, if you don't have the same management classes in the new domains as the old, when you move a client to a new domain you get a lot of errors, and the files get managed by the "grace period" numbers, anyway. Nothing good will happen. Export may be the cheapest solution, overall, although it's gonna get expensive fast since you will quickly double your tape requirements. 1) Change all your management classes to never expire/unlimited versions 2) Make sure NONE of your clients has the delete-backup-data privilege 3) Start your exports, take your time doing them. When done, you have a complete set of data that is external to TSM. You can set up a test server with a small TSM, and do IMPORTS of specific clients as needed, if the investigating agencies ever figure out what they want to look at. (Careful to have your mgmt classes set to never expire/unlimited versions when doing the imports.) THEN you can reset your production system back to normal retention periods, and TSM will purge itself of the built-up extra stuff and move on. Besides that, the best solution I can think of, change all the management classes to never expire/unlimited versions, Copy the DB to your "test" server, lock all the client nodes, put your tapes on a shelf. Save the last DB backup, just in case. Start your production server over with a clean DB, back up everything new and move on. If anybody needs their old stuff, get a copy via export (from test) and import(back to production). That would keep you from (immediately) doubling your tape requirements, will cost you some hardware to make tape available for your test system.. ************************************************************************ Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] "Intelligence has much less practical application than you'd think" - Scott Adams/Dilbert ************************************************************************ -----Original Message----- From: bbullock [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 15, 2002 3:31 PM To: [EMAIL PROTECTED] Subject: Eternal Data retention brainstorming..... Folks, I have a theoretical question about retaining TSM data in an unusual way. Let me explain. Lets say legal comes to you and says that we need to keep all TSM data backed up to a certain date, because of some legal investigation (NAFTA, FBI, NSA, MIB, insert your favorite govt. entity here). They want a snapshot saved of the data in TSM on that date. Anybody out there ever encounter that yet? On other backup products that are not as sophisticated as TSM, you just pull the tapes, set them aside and use new tapes. With TSM and it's database, it's not that simple. Pulling the tapes will do nothing, as the data will still expire from the database. The most obvious way to do this would be to: 1. Export the data to tapes & store them in a safe location till some day. This looks like the best way on the surface, but with over 400TB of data in our TSM environment, it would take a long time to get done and cost a lot if they could not come up with a list of hosts/filespaces they are interested in. Assuming #1 is unfeasible, I'm exploring other more complex ideas. These are rough and perhaps not thought through all the way, so feel free to pick them apart. 2. Turn off "expire inventory" until the investigation is complete. This one is really scary as who knows how long an investigation will take, and the TSM databases and tape usage would grow very rapidly. 3. Run some 'as-yet-unknown' "expire inventory" option that will only expire data backed up ~since~ the date in question. 4. Make a copy of the TSM database and save it. Set the "reuse delay" on all the storage pools to "999", so that old data on tapes will not be overwritten. In this case, the volume of tapes would still grow (and need to perhaps be stored out side of the tape libraries), but the database would remain stable because data is still expiring on the "real" TSM database. To restore the data from one of those old tapes would be complex, as I would need to restore the database to a test host, connect it to a drive and "pretend" to be the real TSM server and restore the older data. 5. Create new domains on the TSM server (duplicates of the current domains). Move all the nodes to the new domains (using the 'update node ... -domain=..' ). Change all the retentions for data in the old domains to never expire. I'm kind of unclear on how the data would react to this. Would it be re-bound to the new management classes in the new domain? If the management classes were called the same, would the data expire anyways? Any other great ideas out there on how to accomplish this? Thanks, Ben
