Content-Type: |
text/plain; charset="utf-8" |
Date: |
Tue, 9 Feb 2010 16:22:19 -0800 |
Reply-To: |
|
Subject: |
|
From: |
|
Content-Transfer-Encoding: |
8bit |
In-Reply-To: |
<010501caa9c0$7c9169c0$75b43d40$@com> |
MIME-Version: |
1.0 |
Sender: |
|
Parts/Attachments: |
|
|
Backups are for recovery and not for discovery. The discovery process of backup tapes (especially when they are older can be extremely expensive as you'd not only need the hardware to read the tapes, but also the software). It is my personal opinion that backup tapes really shouldn't be kept longer than the retention periods you have defined for all the reasons earlier mentioned. The case of Morgan Stanley vs Coleman comes to mind on what issues you could run into (http://www.fulcruminquiry.com/Morgan_Stanley_Ruling.htm)
Jesse brings up another valid point .. end users are simply not going to classify hundreds of email messages every day. It will take them too much time, time taken away from doing their real duties. I see a lot of organizations in this case move to a 'departmental policy' instead.
The cost of going through the haystack is far less than having to go through the firedrill to search the repositories when you don't have one. In fact .. the search and index engines available on such solutions are extremely intelligent and can give you accurate search results in a matter of seconds, where as else you have to do the same manually dozens of times.
And the judge will order you to do so.. for example: In Toussie v. County of Suffolk , the county argued search of backups was overly burdensome. The court narrowed the search request down to 35 terms, but it still required an estimated 470 backup tape restorations at a cost of $600,000-$900,000. (an archiving solution would have cost a fraction of that for them)
Disclosure .. I work for an archiving vendor, but the above statements are my own and don't necessarily reflect my employer.
Martin Tuip
MVP Exchange
Mimosa Systems
[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]
|
|
|