Hi David,
A few years ago I was working for a state health department that had
similar sorts of retention issues and was about to retire their main
patient admin system as they moved to a new one. In this case, even
keeping existing data was not sufficient because different rules applied to
different data. Some of it was supposed to be kept literally forever so
that historians could get at it, some was required for 80 years so that
epidemiological studies could be made, and some had retention lengths that
depended on the life of the patient. In opposition to that, privacy
legislation required that some data be deleted when there was no longer an
operational need for it.
After convincing them that TSM was not an appropriate vehicle, using a
reducio ad absurdum argument, I researched a little further.
The best method for long term data retention is probably flat XML files.
These are well understood and self describing, require no specialist
software to read, yet can be searched by machine when this is necessary,
There are a number of specialized XML dialects developed for different
purposes so a complete re-invention of the wheel is not necessary.
I did not persue this to completion. It turned out that there was a
section in the organization whose primary job was data retention : mostly
paper based, but recognizably moving into data - just think of all those
word documents and spreadsheets that also are subject to legal retention
requirements, and the problem was passed to them.
It did occur to me that there is a business opportunity for consulting on
such problems. Just understanding the web of retention standards, which
tend to refer to other standards nested three or four levels deep is a huge
job, then applying those standards to the data at hand is another in order
to write some code to produce the final XML. It would however take the
sort of analytical accountant/actuary mindset to successfully do this and
that is not my style.
I hope that has given you some insight
Regards
Steve
Steven Harris
TSM Admin, Sydney Australia
David Longo
<[EMAIL PROTECTED]
TH-FIRST.ORG> To
Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
Dist Stor cc
Manager"
<[EMAIL PROTECTED] Subject
.EDU> [ADSM-L] Long Term Data Retention
17/05/2008 01:35
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
Wanted to get some thoughts on what people are doing for
Long Term Data Retention - specifically on obsolete applications.
Say we have an NT 4.0 system that is no longer used. Business
owner says we need to keep for 25 years. I know not
practical/possible for a number of reasons. Even if we Vmware it,
will they support NT 4.0 for 25 years? (Will ANYBODY support
Windows 2008 in 25 years?)
I know even if they take a DB dump and I Archive it for 25 years, if
we retrieve the file 20 years from now, who can decipher it? There
are several systems here that people are giving hints that they want
to do this.
I have hinted that they need to take whatever data and dump it
to a text or pdf file and then I archive that. I realize that this may
not be that simple for some applications as probably involves
more than a simple data dump or whatever. Plus some applications
are spread across multiple servers.
So, before we have big meeting and I push the text or pdf file
idea, what are people doing for retention of data on obsolete
servers/applications?
Thanks,
David Longo
#####################################
This message is for the named person's use only. It may
contain private, proprietary, or legally privileged information.
No privilege is waived or lost by any mistransmission. If you
receive this message in error, please immediately delete it and
all copies of it from your system, destroy any hard copies of it,
and notify the sender. You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient. Health First reserves the right to
monitor all e-mail communications through its networks. Any views
or opinions expressed in this message are solely those of the
individual sender, except (1) where the message states such views
or opinions are on behalf of a particular entity; and (2) the sender
is authorized by the entity to give such views or opinions.
#####################################
