As someone who has migrated from Burroughs Medium Systems (B3900) to
Honeywell (DPS-8) to IBM (4381, 3090, 9672 - MVS, MVS-XA, MVS-ESA) to
IBM RS/6000, I have to agree with Andrew. Any long-term archiving
mandated by the business MUST include archiving of the data in an
UNLOADED format - either csv or fixed field, ascii format (no binary or
packed fields). In addition, the human-readable database schema and
subschemas and the source code to the unload and reload programs need to
be archived.
The cost for this is not trivial. The unload/reload programs should be
tested out. Just about any non-trivial database will take long enough to
flat-file that you'll need to run the process from a copy of the
original. And once it's been unloaded, you need to manage the results.
I would be inclined to agree with Dwight -- this isn't really a TSM
process. I'd think about using tar or pax (primarily because the source
to both is available) to write the archive media (tape, dvd, whatever)
and figure on copying the result about every six months to a year.
Short of that -- and I have yet to get MY corporation to buy into this
-- I have seven archive management classes: one_year, two_year, and on
to seven_year, with retentions amounting to one month longer than the
class name suggests. And an internal memo I dust off from time to time
about why this is a dumb idea. Current archiving activities haven't
really caused database issues in TSM - yet. But the requirement for more
disk space is one of the 'dumb idea' entries.
Good Luck -
Tom Kauffman
NIBCO, Inc
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Andrew Raibeck
> Sent: Monday, July 19, 2004 12:58 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Thoughts on Monthly Archives
>
> > I haven't read the SBO requirements, but from our internal auditors,
> it
> looks
> > like we need to have a good business
> > best efforts to keep readable for whatever retention period we
> publicize.
> >
> > In working with older tape technology in storing archive tapes, we
> found
> > that 20% of the tapes were not readable within 5 years. It seems
> that
> the
> > best idea for long term archives is they need to be re-read on a
> regular
> > basis (annually?) just to make sure they can be read.
>
> Or refreshed.
>
> Actually when I raised the issue of the data being readable, I wasn't
> referring to hardware or media problems (though these are also good
> points), but the availability of software that can "understand" the
> data.
> For example, if you open a .zip file with a plain text editor, the
> content
> will appear as so much garbage. Without a zip program that can make
> sense
> of the data, being able to restore a .zip file doesn't give you
> anything
> useful (at least not without an awful lot of hacking). .zip is a
> common
> format and likely to be available in the future, but what about more
> obscure formats, where maybe you archive the files while you use the
> product? Suppose you switch to a new product that uses a different
> format,
> then decide 10 years from now you need to retrieve the data that was
> used
> by the old product. Will you still have a copy of that old product
> around
> that will run on current operating systems and hardware? Even if you
> archived the software and could in theory restore and run it, do you
> know
> where, amongst all that archive data, the software is? Will your
> successors be able to find the data and the software? Will they even
> know
> which software they need to run?
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive
and confidential use of the intended recipient. If you are not the intended
recipient, please do not read, distribute or take action in reliance upon this
message. If you have received this in error, please notify us immediately by
return email and promptly delete this message and its attachments from your
computer system. We do not waive attorney-client or work product privilege by
the transmission of this message.
|
