Here's my $0.02 on this topic....

Wanda makes some good points pro and con, however I don't think they were
given appropriate weighting.

Whatever product or method is used to store data for 30 years, the problem
of maintaining support and cross-platform data types will plague them all!

I would assume that they are not going to do the archive and then walk away
for 30 years, only to come back and brush the dust off and try and restore.
The restore requirement could be anytime from now until 30 years from now.

Anyway, the comment...
>One nice thing about archiving with TSM is that the TSM server makes it very
>easy to rotate your media, make extra copies for vault storage (copy pools),
>or just move the data to new media at any point.  So you can easily avoid
>the probems associated with aging/obsolete media.
I think outweighs all the other more trivial problems. I still today
occasionally restore files from an archive of my old Windows 3.1 system
onto my Win2K with no problems. TSM is one of the top storage managment
products in use today, so why not stick with it.  If 15 years from now
Tivoli decides to stop supporting TSM, then the storage administrator at
that time will have to come up with a migration strategy.  Hopefully by
then he/she/it will just transfer it to his neo-cortical implant and go
back to playing on the hollodeck :-).

Perhaps use a generic node name, and think about using a separate TSM
server as the Archive server, but definitely do use TSM.

Scott.

At 11:46 AM 1/16/01 -0500, you wrote:
>THIRTY YEARS is a LOOOONG time.
>
>One nice thing about archiving with TSM is that the TSM server makes it very
>easy to rotate your media, make extra copies for vault storage (copy pools),
>or just move the data to new media at any point.  So you can easily avoid
>the probems associated with aging/obsolete media.
>
>However, as much as I like the product, I might think twice about archiving
>with it for THIRTY YEARS.  One disadvantage I see is that the ONLY thing
>that can retrieve the archived data is the TSM client, and you have to
>retrieve UNIX data to UNIX machines, and NT data to Wintel-type machines.
>
>Assuming Tivoli/TSM are viable for the next 30 years, do you want to count
>on your company having the same platforms and running the client code for
>the next 30 years?
>
>Another problem with TSM archiving is that the data is indexed/tied to the
>host that archived it.  It's a real pain to deal with that when you go
>through a server consolidation where multiple machines get merged into one.
>Your archives are still split up and tied to the old host names (been there
>done that one already.)
>
>If I had your requirement, I think I would at least take a look around to
>see if there is something that would leave the data in a form that would
>provide an easier means to see what is archived, without the data being tied
>so tightly to the machine that archived it originally and that machine's
>directory structure.  And if possible, to leave the data machine readable
>directly by multiple pieces of software, without depending on the specific
>TSM client code.  Such a thing may not exist, but I would at least THINK
>about it.
>
>Or at the very least, make sure all your long-term archives are done by ONE
>host.
>
>
>
>
>
>-----Original Message-----
>From: Christoph Pilgram
>To: ADSM-L AT VM.MARIST DOT EDU
>Sent: 1/16/01 3:00 AM
>Subject: Archiving
>
>Hy everyone,
>
>we are discussing the possibilities of archiving data with TSM or other
>products (from NT,UNIX).
>Our requirements are to archive data for about 30 years. TSM is in
>discussion because we use it already for backup ( and in some cases we
>use
>the archive-command ).
>The policy domains for the clients for archiving will be (from my point
>of
>view) totally different to those for backup.
>
>Can anybody share his good (or bad) experience in long term archiving
>with
>whatever kind of library in the background (DVD or tape).
>
>Thanks a lot
>
>Christoph
>
>
Scott McCambly
AIX/NetView/ADSM Specialist - Unopsys Inc.  Ottawa, Ontario, Canada
(613)799-9269