"no mailbox limits" will do funny things to ANY org :) On Tue, Jul 8, 2008 at 10:25 AM, Chris Scharff <[EMAIL PROTECTED]> wrote: > How is it that backups take a long time but you're small enough that > virtualizing shouldn't be an issue? These seem incongruous. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hutchings > Posted At: Tuesday, July 08, 2008 9:26 AM > Posted To: swynk > Conversation: Storage Group and Database Best Practice? > Subject: RE: Storage Group and Database Best Practice? > > FWIW when I ran all the numbers before, we're small enough that > virtualizing shouldn't be an issue, and I'd assumed that there's no > significant performance overhead from running several storage groups > over one? > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Egan, > William > Sent: 08 July 2008 15:23 > To: Exchange Discussions > Subject: RE: Storage Group and Database Best Practice? > > In an ideal world, this would involve separate tran log volumes for each > storage group, with the storage group being the tran log boundary, > correct? If so, this gets expensive from a disk standpoint (in terms of > # of disks required, not necessarily dollar cost.) What are the > real-world consequences of sharing a single RAID1 or RAID10 volume for > tran logs from multiple storage groups? Is it fine since its all still > sequential writes from the I/O profile standpoint? > > Thanks, > bill > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ed > Crowley > Sent: Tuesday, July 08, 2008 10:10 AM > To: Exchange Discussions > Subject: RE: Storage Group and Database Best Practice? > > Creating several storage groups is a good idea. When you set up your > backup > you can back up each storage group separately. I recommend that you > back up > individual stores in each storage group serially but separately so each > has > its own backup file. This will make restoration easier if you just need > to > restore one, and will keep the backup file sizes down. You can do all > this > with a set of batch files. > > Ed Crowley MCITP MCSE+I MCSE+M MCTS MVP > "There are seldom good technological solutions to behavioral problems." > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Hutchings > Sent: Tuesday, July 08, 2008 8:41 AM > To: Exchange Discussions > Subject: Storage Group and Database Best Practice? > > I have six new 15k SAS disks sat waiting to go in our SAN to form the > basis > of a new Exchange Server to replace our existing, full one. > > It's Exchange 2003 SP2 Enterprise. > > The current server has around 150gb of private store, all in a single > database. Suffice to say backups take a long time. > > With the new server I'm looking at using multiple storage groups and > databases so I can (hopefully) backup several stores concurrently. > > We also intend to impose mailbox and message limits on the new server > and > I'm unsure of the best way to do this. We would like to have three > tiers/bands for mailbox sizes, but Exchange seems to offer either store > level quotas, or mailbox level, not group level. > > I'd appreciate any input on how people would approach this. Best > practise > from what I read seems to be that if you want three stores you would > create > three storage groups with one database each vs. one storage group with > three > databases? > > Thanks in advance, > Paul > > > -- > MIRA Ltd > > Watling Street, Nuneaton, Warwickshire, CV10 0TU, England. > > Registered in England and Wales No. 402570 > VAT Registration GB 114 5409 96 > > The contents of this e-mail are confidential and are solely for the use of > the intended recipient. > If you receive this e-mail in error, please delete it and notify us either by > e-mail, telephone or fax. > You should not copy, forward or otherwise disclose the content of the e-mail > as this is prohibited. > > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange > To subscribe: http://e-newsletters.internet.com/discussionlists.html/ > To unsubscribe send a blank email to [EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > To unsubscribe via postal mail, please contact us at: > Jupitermedia Corp. > Attn: Discussion List Management > 475 Park Avenue South > New York, NY 10016 > > Please include the email address which you have been contacted with. > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange > To subscribe: http://e-newsletters.internet.com/discussionlists.html/ > To unsubscribe send a blank email to [EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > To unsubscribe via postal mail, please contact us at: > Jupitermedia Corp. > Attn: Discussion List Management > 475 Park Avenue South > New York, NY 10016 > > Please include the email address which you have been contacted with. > >
_________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
