Have you considdered using archiving to store the data that needs to be kept forever? I've very sure no government org is really intrested in your /etc/passwd file for over 1o years back. Find out what you need to keep and set up archiving....
On donderdag, augustus 15, 2002, at 09:30 , bbullock wrote: > 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 > --- Met vriendelijke groeten, Remco Post SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167 "I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams
