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:
sasha babin <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Fri, 14 Aug 2009 19:51:34 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
My few words to Larry's comments.
 
If somebody keeps information on backup tapes longer then originals...
Ediscovery process will appreciate it, but would your management happy from that?
 
Alex
--- On Fri, 8/14/09, Larry Medina <[log in to unmask]> wrote:


From: Larry Medina <[log in to unmask]>
Subject: [RM] WAS Re: CA Litigation Hold Request NOW: Value of Disaster Recovery Data
To: [log in to unmask]
Received: Friday, August 14, 2009, 2:02 PM


>Margaret wrote: "I was going to do a similar request and with the
>passage of AB 5 in California I'm wondering if anyone is updating their
policies?"
>
>I copied & pasted the following:
>
>AB 5 effectively overrules Zubulake's position that data contained by
>disaster recovery systems was simply inaccessible. AB5, when passed into
>law, will not let the responsible party object to data discovery simply
>based on it's location. Disaster recovery data will now be presumed fair
>game for discovery. Back up tapes contain the large majority of data
>stored for disaster recovery.
>
>So, Margaret, are you saying that you policy said basically that
>Disaster Recovery data was not part of your process & could be ignored?
>
>I may not have seen enough information in regards to AB 5 because I
>couldn't pull up the document, only a summary and passage process but
>still.


Hmmm... as I and others frequently say (no, not it depends, the OTHER thing
about the 'I'm not a lawyer...' )   there's more to this than is printed on
paper.  

The thing to remember here is the definition and purpose of "disaster
recovery data".  The intended purpose is to reinstate systems or recover
from a  catastrophic data loss in the event of a mishap, and once the
generation of data has been replaced by a new set, previous generations
should be discarded in the course of normal business.  

One of the biggest problems is who thinks they own this data, and the lack
of consistent policies and processes about how it is handled.  From the RIM
perspective, NO BACKUPS should be retained longer then the required
retention of the original records they are related to.  This should be built
into business practices, and backups should be generated and cycled to
ensure this is the case across all functional areas of an organization. This
would result in reduced risk and costs associated with having to search for
information that may exist in other sources dusing a discovery request.

Many backup tapes are managed by ITs practices, the old school methods of
son, father grandfather, which result in generations of data that may have
outlived its required retention and business use to satisfy a long-standing
procedure that should be revised to be consistent with business needs. This
was the case in the Toshiba trade secrets case http://bit.ly/167VQO and
others as well.

This is also the fact that is NOT considered by organizations implementing
"e-mail archiving solutions" which are neither an ARCHIVE or a SOLUTION. 
They are a "haystack" that collects all e-mail as it is ingested and stores
it in a massive repository, regardless of its status as a record or its
retention requirements.  And when you have to produce an ESI data map, you
have to declare that you have this source of potential evidence that will
require searching under CA AB5, which clearly explains why this is NOT a
solution to anything for anyone but the plaintiff.

Consideration should be given to ensuring policies and procedures for
managing data stored in backups are consistent across an organization; that
independent backups are made of applications and data, and that data be
segregated by its required retention if it is going to potentially be
retained longer than required to serve disaster recovery needs.

Larry
[log in to unmask]

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]



      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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