There is a huge difference between backup and archive, especially with TSM.
One can actually make them different in TSM.
The keys to effective archiving are three fold:
1. Only archive that which you are legally (or for business purposes) required
to archive and then for only the time required. Rarely is anyone required to
keep everything forever! The requirements are much more specific than that.
Having data around that you are not required to have can be as bad or worse
than not having something!
2. Archive in some commonly readable format. Remember, if you are going to
need to retrieve something it is likely going to be sometime down the road.
How you read that something is critical. Does the application that created the
data still exist? Perhaps not. Thus a binary representation of the data is
probably not going to be easily, if at all, readable. This is especially true
for databases. Consider archiving an export of the data rather than the
database files themselves. This seems a "duh", but often is not considered.
3. IT does not own archiving. The business units that rely on IT own archiving
and its requirements. To expect the IT staff to somehow magically
know/understand the business and legal requirements is absurd. We must be
provided with concise requirements for archiving for us to do a good job. We
must understand exactly what data, how long and what the retrieve time
requirements are. Everything forever is STEWPID!
I wrote a paper on this some time ago. If anyone is interested, email me
privately and I'll be happy to send it to you.
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
David McClelland
Sent: Tuesday, August 04, 2009 11:57 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Another perspective on ridiculous retention
Questions flood into my head along the lines of 'what's the difference
between a backup and an archive' (obviously not in a TSM sense) and if/
how should they be treated differently practically with TSM (e.g. a
seperate TSM Server instance for archival purposes, as some places do
etc).
/David Mc
Sent from my iPhone
On 4 Aug 2009, at 18:45, Troy Barnhart <TBarnhart AT RCRH DOT ORG> wrote:
> Only 7 years? We're in Healthcare. Seven is usually the minimum.
>
> If you're talking Minors, then it is 18+7= 25 years. "Digital
> Mammography" & "Research-related" electronic medical records are
> FOREVER. There are lots of numbers on time-retention floating
> around out there - it just depends on the "governing authority". We
> haven't completed our Retention Policy, so we have tapes from
> various Operating Systems and Applications from the 1990's.
>
> Regards,
>
> Troy Barnhart, Sr. Systems Programmer
> tbarnhart AT rcrh DOT org
> Regional Health, Inc.
> 353 Fairmont Boulevard
> Rapid City, South Dakota 57701
> PH: 605-716-8352 / FAX: 605-716-8302
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Shawn Drew
> Sent: Tuesday, August 04, 2009 11:15 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Another perspective on ridiculous retention
>
> "Do I understand you to say you have to keep your NDMP backups
> around for
> 7 years? The tape media isn't even meant to last for 7 years. Do
> you
> have customers that actually think they will need 7 year old copies
> of you
> NAS data? That's a tough requirement."
>
> I thought I'd change this to a new topic. I hear this type of comment
> alot on backup forums. From an engineering perspective, it completely
> makes sense. It also makes sense that people in backup forums
> think like
> engineers!
>
> Just another perspective. When I started with TSM, I was working
> for a
> software development company named "Tivoli" who obviously cared about
> their backup data. The mantra of the backup guys was "Restores are
> more
> important than backups!" I.E. do periodic test restores, and if a
> restore request comes in and conflicts with a backup. cancel the
> backup
> in favor of the restore.
>
> Several years later, I start working for a bank. After working here
> for a
> few years, I realize the mantra is now the reverse: "Backups are more
> important than restores". Meaning. the main reason we perform
> backups
> and retain them for 7 years, is so we can show an auditor our
> settings and
> say we've done it.
> We very rarely have to restore anything that old, but we very often
> have
> to show records of these backups.
>
> One last note, I have been involved in legal discovery projects
> where we
> actually did have to restore 7 year old data off of old DLT IV
> tapes. We
> found tapes with dried up BBQ sauce on them and all sorts of damage.
> Luckily, between the multiple storage pools we were able to rebuild
> all
> the data. The DLTs never actually failed due to age (only by a
> tomato-based attack!)
>
> Regards,
> Shawn
> ________________________________________________
> Shawn Drew
|
