RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Patrick Cunningham <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Mon, 7 Dec 2015 09:14:40 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (67 lines)
I'm not certain that there are any books, as such.

We don't include backup data on our retention schedule. Backups of the
enterprise systems are considered an operations process and we document
that as such. We very clearly define a "backup" and an "archive". A backup
is done with a standard series of rotations and generally not maintained
more than 90 to 180 days. The data is automatically purged by the rotation
process. A typical series of backups is five rotations. We recently found
that our outsourcer was maintaining additional levels of "backups" that
were being maintained indefinitely. We have stopped this practice.

An "archive" is a snapshot of data, taken at designated points in time.
This is subject to a retention period.

Many organizations that have gone to the cloud or other high availability
systems do not maintain backups, as such. Many cloud and other high
availability systems rely on real time updating of production systems,
maintaining a mirrored system that is geographically dispersed. The nature
of these systems drastically reduces the need for traditional backups.
However, your organization should conduct a risk assessment before
considering the elimination of traditional backups, even with high
availability systems.

Any discussion of backups needs to be with your IT Operations team to
understand what they need in order to recover systems. In addition, you
need to talk to the data owners to determine what they need to archive and
how they perceive backups.

The risks of unnecessarily maintaining backups include:

- The need to stop rotation of backup media in the event of litigation.
This can become very expensive, requiring the purchase of additional backup
media as well as the cost of maintaining the backup media.
- Backups very often do not restore as planned. It is important to
regularly test the media and ensure that the media can be restored. Media
that sits around can degrade and may not be capable of restoration. Any
electronic media that is stored should be periodically exercised and tested
for degradation. This is expensive.
- If data exists, it may have to be produced and searched in litigation.
Having large volumes of stored media on hand can lead to very expensive
litigation expense.
- In years past, we had a very strict policy that required Legal approval
before the restoration of an email backup. In other words, if a user
accidentally deleted an email (or their entire email file), IT would not
restore that email without Legal approval. We treated backups as strictly
for disaster recovery purposes and not as routine file recovery tools. By
doing so, we indicated that restoring and recovering data for a single user
was burdensome. That argument was to be made if an opposing litigant
demanded backups to be preserved. There is an entire body of discussion
around "burden" and "proportionality" when it comes to e-discovery.

If you walk in to a tape library and see reel to reel data tapes, it is
very likely time for a tape audit. If the guys running the tape library
mention that they have other media for which they don't have drives, it is
time for a tape audit. Many organizations find thousands of tapes being
retained with no retention period or a very long retention period, simply
because no one ever bothered to assign a retention (or assigned "99" -- 99
years).


Patrick Cunningham

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]

ATOM RSS1 RSS2