Thanks for your input Andy, yes these are all valid points.
The requirement that we have is to be able to go back to the time of a decision
and have available all pertinent information so that the same decision could be
made again. I don't know who the optimist was who wrote the requirement, but
somehow he got it approved by goverment, and I daresay it will take 10 years
before the practical difficulties cause the requirement to change.
My approach would be to specify archiving functionality in EVERY new
application that is installed with a plain-text unload method such as XML.
Then, there needs to be an archive process attached to every old application as
it is retired.
The issue here is not so much to hold every record, but to hold every record
*once* rather than multiple times. I understand that this function is mandated
to be in all new systems by 2006. I'm having trouble finding new employment in
my current specialities (AIX and TSM - its a very small pond where I am) so
I'm thinking of getting ahead of the game and becoming an archiving consultant.
It will certainly be a world wide growth sector for the next few years. Every
Queensland state government department will need to be doing a project in this
area in the next year or two.
Regards
Steve.
>>> storman AT US.IBM DOT COM 20/07/2004 2:25:00 >>>
Some considerations for long-term archive:
- Much of today's data, as it is used from day to day, exists in some
product-specific format. If you were to retrieve that data, say, 10 years
from now, would you have software capable of reading that data?
- Even if you archive the software, will operating systems 10 years from
now be able to run that software?
- Even if you archive the operating system installation files, will the
hardware 10 years from now be able to install and run that operating
system?
- There is a good case to consider carefully what gets archived and how
you archive it.For instance, maybe for database data, it would make sense
to export that data to some common format, such as tab- or comma-delimited
records, which is very likely to be importable by most software. Likewise,
for image data, consider a format that is common today and likely to be
common tomorrow.
- 10 years from now, the people that need to retrieve the archived data
will probably not be the same people who originally archived the data.
Will your successors know what that data is? Will they know how to get to
it? ("Gee, we need to get at the accounts payable database from 10 years
ago... under which node is it archived?") Will they know how to
reconstruct it, and how to use it?
I am by no means an expert in this area, but these are some things to
consider carefully for long-term archives. Note that most of these issues
are not directly related to TSM, but apply regardless of which data
storage tool you use.
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.
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the
sole use of the intended recipient(s). This confidentiality is not waived or
lost, if you receive it and you are not the intended recipient(s), or if it is
transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is prohibited. It may be subject to a statutory duty of confidentiality
if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email in
error, you are asked to immediately notify the sender by telephone or by return
email. You should also delete this email and destroy any hard copies produced.
***********************************************************************************
|
