Slashdot Mirror
What Corporate Email Limits Do You Have?
roundisfunny wonders: "We currently do not have any mailbox restrictions for our Exchange users - which has led us to have a 420 GB mail store for 320 users. Our largest mailbox has over 13 GB in it. One of the main concerns for us is the time it takes for a restore. We have encouraged archiving, but now have 250 GB of .pst files. What sort of limitations does your company have on mailbox size, amount of time you can keep mail, and archives? Please mention your email platform, type of business, and number of users."
If you were to run a different mail server, where not all the info was stored in huge databases (like Exchange) I can guarantee the backup process would be much easier. For example, if you were to run cyrus-imapd and store all the mail as files on a filesystem, and then come up with any backup plan, it would be 10x easier to perform and backup/restore than with Exchange. Exchange's flaws come in the fact that it has those huge databases to contend with, and if you were dealing with a filesystem, a restore is extremely simple and precise.
YOU'RE WINNER !
Another lame blog
You haven't provided nearly enough information for any answer you get to be useful. For example, there are lots of good reasons to keep that data. Business needs may (or may not) be obvious but you may also, depending on your business have regulatory requirements.
If you don't have regulatory and compliance issues, and almost everyone does these days, then you can set a much smaller mailbox size and enforce archiving or deletion. In my environment, 15000 Exchange users with heavy regulatory and compliance requirements, we allow 100MB for the typical user, 250Mb for a supervisory employee, 500MB for middle management and 1Gb for some really higher ups. We have a total of just under 2TB of live maail at the moment, and roughtly 10tb archived.
There are alot of really cool products on the market like CommVault DataMigrator for Exchange, and EMC email extender to make alot of this seamless for you. You can use these produicts to move all of the stale (and you can define stale according to a bunch of different criteria) data off to slower (ie cheaper) storage and out of your message stores. The mail migrator will leave a stub in exchange which looks just like a mail message in outlook. The only difference is that if someone opens one of these older messages they have to wait a couple of seconds while it is brought back into the message store. The whole process is transparent.
These products aren't cheap, but they wind up saving a ton of money, as well as improving performance because you can use much less fast storage for email, your backup needs decrease by a huge amount since you only archive like once a month (and therefore only back that data up once a month), and as a bonus you can easily meet all regulatory and compliance requirements.
If privacy had a tombstone it would read "We did it for your own good" . -- John Twelve Hawks
Actually, in Exchange, replies and CCs don't matter much. If you have forty people with the same 100mb attachment, it takes up only 100mb in the store, plus forty pointers. (tiny). And if 35 of those people 'delete' their attachment, the 100mb will still be used; your database size will barely shrink. Only if all references to an object are deleted will the space be auto-reclaimed. You can run into a problem when it's forwarded out of the company and then forwarded back IN, but as long as it stays within Exchange, it's just a bunch of pointers, not a bunch of 100mb attachments.
:) Once upon a time, I liked having people be able to email everything... but files have gotten so huge, and storage and backup for a big Exchange server is so obscenely expensive, that I regretfully discourage it now.
Limiting attachment sizes seems to curb the worst of the problems... but a lot of non-technical people will scream and kick about having to upload files to a server. When you explain to them that email storage is extremely, extremely expensive (because it has to be hyper-reliable), and website storage can be very cheap, they're often more accommodating. And you can usually automate it fairly well with a good client, like VanDyke's stuff.
I usually offer to set up a cron job to wipe a web transfer directory every day... this means the user doesn't need to remove the files they've uploaded. (so they don't give today's files to tomorrow's recipient by accident.) Some people like that: some people don't. Some want both a temporary and a permanent site, which is easy to set up.
Routine external-user password changes are a very good idea in this kind of setup. Fortunately, it's easy to script. It can run with the file-wipe.... autogenerate a new http auth password for the day and email it to the user. If there were no files to wipe, don't make a new password.
Whatever they like is cool with me, as long as they don't use Exchange for file storage.
What!? Why do you get to dictate what e-mail is for?
E-mail is a service used by employees to get work done. In the case of marketing/sales types, 1GB of saved e-mail is common, and it's critical business data. Yes, some of that data is binary, but it is critical.
Often administrators impose quotas, let the users whine a bit, and then the whining subsides. The adminstrators think that the problem is solved; nope, what actually happened is that all that critical e-mail just got moved to local folders. When that local hard disk inevitably crashes, taking the critical data for a $1 million sales deal along with it, the whining will turn to screaming.
The solution (in my opinion) is for administrators and companies to reevaluate how much e-mail is worth to users. For many, I'd argue it's worth many thousands of dollars. I'm sure some of that money could be used for a reasonable amount of storage.