Dang, my mails are long-winded. Forgive me if I'm boring those of
you who are not interested. Fell free to use the "delete" button. :-)
There's been a lot of good suggestions sent to me. The real kicker
is that with the volume of data involved (460TB as of today), some of the
solutions do not scale well, in that they will take months to complete, or
cost $100,000s in tapes to execute.
Like most of you out there, we gradually grew to our current size,
and management can take the constant nickel and diming we do to keep ahead
of the capacity curve. A big $$ expenditure to CYA for a "what if" will not
sit well with management and they will look to me for "creative
alternatives".
I actually called Tivoli and discussed it with a level 1 & 2 and
here's what I/we came up with.
We have 2 kinds of data: Mission Critical data that we keep in a
copypool, and non-critical/old data we do not backup to a copypool.
Unfortunaly, ALL of the data needs to be retained and the non-critical
(unduplicated) portion is rather substantial in size.
Here's a 1000-ft view of what we are thinking about:
Take a backup of the TSM DB. Make it so that copypool tapes will
never be reused "reusedelay=9999". As production rolls on, all copypool
tapes will be taken from scratch, so the old data we are trying to retain
should remain on the copypool tapes, although at some time, the production
DB may remove their BD pointers through it's "expire inventory" process. Our
growth in copypool tapes is much more reasonable (10-20 tapes a week), and
not costly enough to freak management out.
In the case of the old data being needed, the TSM database can be
restored on a test host & the primary tape volumes marked as inactive. When
a restore is needed, the TSM server will request the copypool tapes, and the
data will still be intact because they have not been re-used. This portion
is pretty much like a disaster recovery test.
The non-critical data is a little harder, as there is only 1 copy of
the data. We could try to push it to a copypool, but there is a LOT and it
will take quite a bit of time $ money. The good thing is that this data is
~only~ being retained for the investigation and no other purpose. For this
reason, daily operations, and file restores will ~never~ need these tapes.
We will check all these primary tapes out of the library at the same
time we take the DB snapshot and box them up with BIG RED letters and put
behind a barber wire fence guarded by vicious dogs. We will then mark the
tapes as DESTROYED on our production database. We might even delete the
filespace, as they are just that useless, however we are going through all
this trouble because they are required because "ALL BACKUPS/ARCHIVES" are
required to be retained.
If we need to restore data off of one of these tapes, we will
restore the TSM DB backup to our test host. These tapes should all still be
marked as "readw" on the restored DB, so we should just be able to restore
the data by feeding it the primary tapes it requests.
Benefits:
- No need to duplicate the data with a "export data" or making a 3rd
copypool copy.
- Very little extra $$.
Problems:
- More work and time up front to make sure it works as planned.
- Care needs to be taken and procedures in place so that copypool or
primary "useless data" tapes are not accidentally reclaimed.
- Might interfere in a true disaster, as the copypool tapes might be
in the wrong place because of an "investigation related" restore.
What do you think? Does it sound like it would work? I ~think~ it
sounds do-able. Am I missing a big GOTCHA anyone can see?
Thanks,
Ben
