At 10:26 AM 2/2/2005 -0800, you wrote:
>Our IS
>department is looking at how long to keep back up tapes and what is the
>best way to keep them.  Currently they are still retaining all back up
>tapes from the beginning of the company 28 years ago.

EEK!!!  I'm not sure you want to broadly publicize this, especially if you
have (or anticipate) ANY potential litigation on ANY SUBJECT...

>I know this is a
>records management issue but at least it is being addressed and the
>network guy who is investigating this issue will listen to what I have
>to say.

There is a need to clearly identify hat they are referring to as "backup
tapes" and what they actually use them for.  The classic definition of a
"backup tape" is something that is used to reinstall a system in the event
of a catastrophic loss of data due to some system mishap or a user "hitting
the wrong combination of keys" that results in the loss of a significant
volume of data.  These are typically made in a very rudimentary, serial
manner as a snapshot of an individual system and/or a server that a number
of users are connected to. In some organizations, there are two types of
backups performed... a full system backup periodically (which is appended
with incremental backups of changed or new files only) and "snapshot"
backups, which only look at document and data files, ignoring any
applications or other stagnant file types.

If your organization has desktops linked to servers, a common practice is
for the full periodic with incremental updates type of vabckup to be made
to "local servers", and then the local servers are backed up off-line
(generally after hours) to a tape system.  These tapes are then stored
somewhere by the IS/IT department and are generally in a rotation system,
and are overwritten every X days/weeks/months.

If everything works right, they are stored in appropriate environmental
conditions to extend the life of the tapes so they are useful when needed
and the tapes are stored in UL 72 approved devices and/or in NFPA232
compliant storage facilities... but at minimum in compliance with NFPA75,
if they are stored on-site.

>Unfortunately, it sounds like he is under the gun and needs to
>come up with a solution in a couple of weeks.

You may want to remind him that "haste makes waste" and the last factor
that should be involved in such a critical decision would be to establish a
timetable before performing a needs analysis.  While no one expects a
disaster to occur, part of running an effective records management program
is planning for one.  Take into account business continuity concerns as
well as vital records protection when considering what to do with the
management of these information assets.

>At this point he is
>thinking of storing them at Iron Mountain with their electronic
>archives.

Well, let me say this about that... =^)

>We do have a retention schedule but it needs a lot of work.  At this
>time it only covers hard copy project files.

I would change this to state "We are developing a retention schedule..."
because to have a "schedule" for one series of records doesn't constitute a
schedule. =)  A retention schedule is a critical component of a Records
Management Program, and the most important part of the program is a Records
Management POLICY.  And a part of the policy should include the language
that "...approved and established retention periods apply to ALL RECORDS,
irrespective of the media, form or format they are maintained in or on..."

Larry

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance