I agree with Bill.
A few years ago I had to look at saving health data. Some of this was
mandated to be kept literally forever as it fell under the State's Archive
Act, more had to be kept for 70 years. Also surprisingly, some was not to
be kept at all once its "operational" purpose had expired, eg addresses.
The only archive medium that made any sense was something optical
containing the simplest of file systems and XML files with the unloaded
data in ascii. It is cheap, has a long life and is as software independent
as it can be.
Think that we went from wax cylinders to compact disks in 100 years, and
try to imagine what we'll be using 50 years from now.
Regards
Steve
"Evans, Bill"
<bevans AT FHCRC DOT ORG
> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: [ADSM-L] LTO for long term
archiving
06/05/2009 07:34
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
I truly doubt that archiving drives, servers and tapes for 25 years each
time the technology updates will let you read the tapes because the
drive and server will probably not even boot up and run.
You will have to update the data every two LTO cycles or so. LTO will
read two generations back and 25 years from now we will be on LTO14 or
15, so LTO4 is toast. Or, more probably, we will be storing into some
kind of flash drive at Petabyte capacities.
I think that Blu-Ray DVD will meet your 25 year mark without having to
retrieve and update to new media. I know that my 1986 CD's (those not
seriously scratched or warped from laying on the dash ) still work on
today's systems. Properly stored DVD's would need to have players
stored also, but, these are mechanically simpler than LTO drives and
servers and would most likely still run. They are also much cheaper, so
having a new DVD in storage every 5 years is no big expense.
The bigger issue is where and how do you keep track of all of this? I
think TSM's HSM is probably capable, however, I'm not real comfortable
recommending it. We have had several years of problems running HSM on
Solaris and have finally turned it off.
What is needed is a good archiving tool that can keep an updated DB of
content and storage location that users can browse.
We recently restored a power point file written by Office version (?) on
an OS 9 Mac. This could NOT be read by Office XP, 2003, 2007 (PC) or
Office 2004 or 2008 (Mac). We had to find an old Mac OS/9 that still
had a copy of Office 2000, read it, write it back to the 2000 version
.ppt file before any 2004-2009 software could read it. If it had been
18 years instead of 9 years, then we never would have been able to read
it at all, that old OS 9 Mac would never have been saved.
This will happen more and more as our programs become more complex and
require significant changes in the file formats. So the real problem is
not just how to archive the data for 25 years, it's how to archive the
applications for 25 years so we can access that data!
Actually, stone tablets are, so far, the best archive media...
Thanks,
Bill Evans
Research Computing Support
FRED HUTCHINSON CANCER RESEARCH CENTER
206.667.4194 ~ bevans AT fhcrc DOT org
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Kelly Lipp
Sent: Tuesday, May 05, 2009 1:42 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] LTO for long term archiving
I like the implication, but I'm pretty sure somebody actually thought
being able to read the information would have been a good idea.
Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777 x7105
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Remco Post
Sent: Tuesday, May 05, 2009 2:39 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] LTO for long term archiving
I do agree, having the tapedrives around _could_ be important. I know
of at least one environment that was able to produce the media that
stores the data, but no drives. But then again, they only had to
retain the data, not the infra to access it.
On May 5, 2009, at 22:35 , Kelly Lipp wrote:
> To me the problem is having the drives around and more importantly,
> the interfaces to the drives. I think that probably the best bet is
> to plan on "archiving" a TSM server with a drive along with the
> media periodically. Snap off the last database backup, restore it
> on the to be archived server (a good test in itself), and store the
> whole kit together. If one needs to retrieve an archive, fire up
> the archived server, query the database to determine what tape is
> required, get it, retrieve the data and put the whole mess away.
>
> The other way to do this would be to migrate the archived data to
> new tape media as you march through time. I like this approach as
> that will have the double advantage of refreshing and verifying the
> data on those tapes. One could shelve the media in the archive
> pools and do this on a very controller basis when the media
> changes. Lots of data movement potentially, but it would become a
> nicely verified process that your auditors could look at to help
> ensure compliance. It's one thing to say we're doing and quite
> another to show we're doing it. Having the archive data more
> readily retrievable has obvious benefits as well.
>
> Kelly Lipp
> CTO
> STORServer, Inc.
> 485-B Elkton Drive
> Colorado Springs, CO 80907
> 719-266-8777 x7105
> www.storserver.com
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Huebschman, George J.
> Sent: Tuesday, May 05, 2009 2:25 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] LTO for long term archiving
>
> Does anyone have 25 year old tape media or tape drives around?
> Will you stil be able to use LTOx media in 25 years?
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of
> Thomas Denier
> Sent: Tuesday, May 05, 2009 4:11 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] LTO for long term archiving
>
> I work for a large hospital. I have been asked to investigate possible
> configurations for archiving something between a few hundred terabytes
> and a petabyte of data for 25 years. This would be clinical records
> that
> we need to keep in case of a malpractice suit. The retention period is
> 25 years because there are two ways we can get sued for alleged
> malpractice involving a pediatric patient. The parents or guardians
> have
> a seven year window of opportunity to file suit, starting at the
> time of
> the alleged malpractice. The patient has a seven year window of
> opportunity, starting at his or her 18th birthday. In principle, the
> retention period should vary depending on patient age, but nobody I
> have
> talked to so far thinks it is practical to sort records in this way;
> they want a uniform retention period that covers the worst case
> scenario
> (a patient allegedly harmed as a newborn suing just before the end of
> his or her seven year window).
>
> As far as I can tell, the most expensive part of such a
> configuration is
> the media, and LTO media will cost about a third as much as the most
> economical MagStar media (extended length 3592 volumes read and
> written
> with TS1130 drives). With the sort of workload described above I don't
> expect any difficulty staying within the recommended limit on the
> number
> of times an LTO volume passes over the tape heads. Are there any other
> reasons to be nervous about using LTO for long term archives?
>
> IMPORTANT: E-mail sent through the Internet is not secure. Legg
> Mason therefore recommends that you do not send any confidential or
> sensitive information to us via electronic mail, including social
> security numbers, account numbers, or personal identification
> numbers. Delivery, and or timely delivery of Internet mail is not
> guaranteed. Legg Mason therefore recommends that you do not send
> time sensitive
> or action-oriented messages to us via electronic mail.
>
> This message is intended for the addressee only and may contain
> privileged or confidential information. Unless you are the intended
> recipient, you may not use, copy or disclose to anyone any
> information contained in this message. If you have received this
> message in error, please notify the author by replying to this
> message and then kindly delete the message. Thank you.
--
Met vriendelijke groeten,
Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622
|
