<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Ouch! Missing e-mails get company socked with big fine</title>
	<atom:link href="http://www.docucrunch.com/ouch-missing-e-mails-get-company-socked-with-big-fine/feed" rel="self" type="application/rss+xml" />
	<link>http://www.docucrunch.com/ouch-missing-e-mails-get-company-socked-with-big-fine</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Mon, 08 Aug 2011 21:53:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: The Top 10 Stories of 2009! &#124; DocuCrunch.com</title>
		<link>http://www.docucrunch.com/ouch-missing-e-mails-get-company-socked-with-big-fine/comment-page-1#comment-1148</link>
		<dc:creator>The Top 10 Stories of 2009! &#124; DocuCrunch.com</dc:creator>
		<pubDate>Tue, 05 Jan 2010 17:34:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.docucrunch.com/?p=1316#comment-1148</guid>
		<description>[...] Ouch! Missing e-mails get company socked with big fine [...]</description>
		<content:encoded><![CDATA[<p>[...] Ouch! Missing e-mails get company socked with big fine [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PJ</title>
		<link>http://www.docucrunch.com/ouch-missing-e-mails-get-company-socked-with-big-fine/comment-page-1#comment-131</link>
		<dc:creator>PJ</dc:creator>
		<pubDate>Wed, 12 Aug 2009 18:06:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.docucrunch.com/?p=1316#comment-131</guid>
		<description>Honestly, I am guessing that the judge has never been through the process of having to parse through TB and TB of info. Most people forget that storage space (esp on backups) is not large enough to accomodate the amount of documentation/emails/logs/files that are produced each day/week/month/year. 

Let&#039;s say the company uses Exchange Server for email, and Backup Exec for backing up those emails. 

The largest mailbox size that a user can have is 75gb (Exchange 2003), but unless you have the funds to purchase a powerful server, most admins will limit that size to way less than that, otherwise users complain of slow/laggy email delivery/use.

This leaves users to either 

1. Delete Emails - This means the email doesn&#039;t exist currently on the Exchange server. If the user didn&#039;t make a copy of the email in an archive somewhere, then the IT Dept has to restore from backup. 

The issue with restoring from backup is that it IS a time consuming process. Backup Exec doesn&#039;t allow you to search the backups for specific words located in email. You have to restore the emails in order to do the search. 

However, there are going to be more emails than what the mailbox can hold, so you have to restore the emails in chunks (generally by date range), search through those emails, get rid of the emails that are not relevant (don&#039;t need to include the emails where you were telling your best friend that you got your wife a camera for Christmas), print the ones that are, lather, rinse, repeat. 

Not too bad if you are just looking at the past 2 weeks of emails, but the longer date range being parsed, is the longer amount of time it will be to try to restore info. 

2. Archive off emails.

If they archive off emails to PST files, then they are limited to a 2GB limit, before having to create a new PST file. Now the IT department has to restore every PST file for the user, before they can do the search. That means you have to locate the media (tape/hard drive/CD) that has the PST file on it, mount it, inventory it, find the file you want to restore, and start the restore process. 

To put this into perspective, we backup about 50gb worth of data every night (and that is because we only backup what has changed). It takes 2.5 hours to backup that much data. Depending on where you are restoring to, generally speaking, restore takes 2x-3x as long to process, which means that restoring 50gb for one night would take 5-7.5 hours just to get the files/emails to a state where you could start a search. 

We are a small company (&lt;100 employees). I can&#039;t imagine how much data that Dell backs up every night.....and goodness, where in the heck would they store it all? At 50GB each night, a 1 TB hard drive would fill up in no time (assuming you never overwrote the data on the backups). 

I think people making decisions about a timely manner/method on discovery need to understand the process before blindly making judgements.</description>
		<content:encoded><![CDATA[<p>Honestly, I am guessing that the judge has never been through the process of having to parse through TB and TB of info. Most people forget that storage space (esp on backups) is not large enough to accomodate the amount of documentation/emails/logs/files that are produced each day/week/month/year. </p>
<p>Let&#8217;s say the company uses Exchange Server for email, and Backup Exec for backing up those emails. </p>
<p>The largest mailbox size that a user can have is 75gb (Exchange 2003), but unless you have the funds to purchase a powerful server, most admins will limit that size to way less than that, otherwise users complain of slow/laggy email delivery/use.</p>
<p>This leaves users to either </p>
<p>1. Delete Emails &#8211; This means the email doesn&#8217;t exist currently on the Exchange server. If the user didn&#8217;t make a copy of the email in an archive somewhere, then the IT Dept has to restore from backup. </p>
<p>The issue with restoring from backup is that it IS a time consuming process. Backup Exec doesn&#8217;t allow you to search the backups for specific words located in email. You have to restore the emails in order to do the search. </p>
<p>However, there are going to be more emails than what the mailbox can hold, so you have to restore the emails in chunks (generally by date range), search through those emails, get rid of the emails that are not relevant (don&#8217;t need to include the emails where you were telling your best friend that you got your wife a camera for Christmas), print the ones that are, lather, rinse, repeat. </p>
<p>Not too bad if you are just looking at the past 2 weeks of emails, but the longer date range being parsed, is the longer amount of time it will be to try to restore info. </p>
<p>2. Archive off emails.</p>
<p>If they archive off emails to PST files, then they are limited to a 2GB limit, before having to create a new PST file. Now the IT department has to restore every PST file for the user, before they can do the search. That means you have to locate the media (tape/hard drive/CD) that has the PST file on it, mount it, inventory it, find the file you want to restore, and start the restore process. </p>
<p>To put this into perspective, we backup about 50gb worth of data every night (and that is because we only backup what has changed). It takes 2.5 hours to backup that much data. Depending on where you are restoring to, generally speaking, restore takes 2x-3x as long to process, which means that restoring 50gb for one night would take 5-7.5 hours just to get the files/emails to a state where you could start a search. </p>
<p>We are a small company (&lt;100 employees). I can&#8217;t imagine how much data that Dell backs up every night&#8230;..and goodness, where in the heck would they store it all? At 50GB each night, a 1 TB hard drive would fill up in no time (assuming you never overwrote the data on the backups). </p>
<p>I think people making decisions about a timely manner/method on discovery need to understand the process before blindly making judgements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: joseph martins</title>
		<link>http://www.docucrunch.com/ouch-missing-e-mails-get-company-socked-with-big-fine/comment-page-1#comment-110</link>
		<dc:creator>joseph martins</dc:creator>
		<pubDate>Thu, 30 Jul 2009 00:13:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.docucrunch.com/?p=1316#comment-110</guid>
		<description>Token sanctions are not enough incentive to change behavior, Sam. A $25k fine for Dell accomplishes absolutely nothing at all.

The inconsequential sanction itself is a mockery of our judicial system.</description>
		<content:encoded><![CDATA[<p>Token sanctions are not enough incentive to change behavior, Sam. A $25k fine for Dell accomplishes absolutely nothing at all.</p>
<p>The inconsequential sanction itself is a mockery of our judicial system.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ouch! Missing e-mails get company socked with big fine &#124; India LPO</title>
		<link>http://www.docucrunch.com/ouch-missing-e-mails-get-company-socked-with-big-fine/comment-page-1#comment-107</link>
		<dc:creator>Ouch! Missing e-mails get company socked with big fine &#124; India LPO</dc:creator>
		<pubDate>Wed, 29 Jul 2009 13:51:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.docucrunch.com/?p=1316#comment-107</guid>
		<description>[...] here to see the original: Ouch! Missing e-mails get company socked with big fine AKPC_IDS += &quot;2369,&quot;;Popularity: unranked [...]</description>
		<content:encoded><![CDATA[<p>[...] here to see the original: Ouch! Missing e-mails get company socked with big fine AKPC_IDS += &#8220;2369,&#8221;;Popularity: unranked [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- This site's performance optimized by W3 Total Cache. Dramatically improve the speed and reliability of your blog!

Learn more about our WordPress Plugins: http://www.w3-edge.com/wordpress-plugins/

Minified using disk
Page Caching using disk (user agent is rejected)
Database Caching 5/13 queries in 0.010 seconds using disk

Served from: lamp03.pbp.com @ 2012-02-11 10:41:25 -->
