In my experience, if you have very large information stores, it may be helpful to split them into separate storage groups. This way you could create separate backups jobs. And then you could manipulate those backup jobs independently from each other.
Especially in my case where in addition to Legato backups I run NTBACKUP to a file (can't trust Legato alone after a few incidents). I have a storage group that has multiple stores and all together they are 60+GB. It takes a long time to do a 60GB backup, plus that's a hige file to handle. I have recently created another storage group and moved half of the users to the stores in the new storage group. Now I have separate NTBACKUP jobs for each storage group. -----Original Message----- From: Bailey, Matthew [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2003 4:38 PM To: Exchange Discussions Subject: RE: Second Storage Group or Additional Mailbox Store Thanks Andy, that is very helpful. - Matt > -----Original Message----- > From: Webb, Andy [mailto:[EMAIL PROTECTED] > Sent: Monday, June 09, 2003 1:36 PM > To: Exchange Discussions > Subject: RE: Second Storage Group or Additional Mailbox Store > > > I thought I covered that already. > > The extra storage group lets you split those users into a separate > backup/recovery set. That's not to say you can't get one > database back > if there are more than one in a single storage group though. > It just may > take longer in the single SG situation. Emphasis on "may". > > You can set a storage group to circular logging. Not a good idea for > VIP mailboxes, but perhaps useful for public folder replicas > or newsfeed > public stores. > > You can set a storage group to zero out deleted database > pages. This is > not a major feature, nor performance hit. > > Policies are set on a mailbox store basis though, so you can get that > functionality without the additional overhead of the extra SG. > > Performance would only improve marginally if at all either > way. If you > put the two sets of log files on two separate sets of disk spindles, > then you would increase your log throughput. On the other hand, you > would be losing single instance store and so would be writing > more into > the databases (both STM and EDB) and using much more RAM for overhead > rather than data caching. > > I don't see the benefit in a small environment of an > additional SG. The > additional IS gives you policy differentiation, so that might be the > argument there. > > > -----Original Message----- > From: Bailey, Matthew [mailto:[EMAIL PROTECTED] > Posted At: Monday, June 09, 2003 2:55 PM > Posted To: Microsoft Exchange > Conversation: Second Storage Group or Additional Mailbox Store > Subject: RE: Second Storage Group or Additional Mailbox Store > > > Then what is the upside? Why would you want two Information Stores? > > - Matt > > > > > -----Original Message----- > > From: Webb, Andy [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 09, 2003 12:02 PM > > To: Exchange Discussions > > Subject: RE: Second Storage Group or Additional Mailbox Store > > > > > > The downside is: > > 1) it uses much more RAM to add a storage group vs. adding > a database > > or just staying with one. > > 2) it uses more space because there is a second set of STM and log > > files and single-instance-store is broken. > > 3) it may take more backup time and backup tape > > > > I'm not arguing against doing it. Just stating facts. > > > > > > -----Original Message----- > > From: Bailey, Matthew [mailto:[EMAIL PROTECTED] Posted > At: Monday, > > June 09, 2003 12:11 PM Posted To: Microsoft Exchange > > Conversation: Second Storage Group or Additional Mailbox Store > > Subject: RE: Second Storage Group or Additional Mailbox Store > > > > > > > > > > > > > You don't say anything about why you think you need another > > database, > > > so there's not much more to recommend. > > > > > > > > > > Because my boss wants it. :-) > > > > The thought was to move the "VIP" users (read - the > accounts that are > > exceptions to the rules - mailbox size, mailbox cleanup, > etc.) to the > > second IS. I am still unclear if it improves performance > to balance > > users across multiple IS. > > > > Are there good reasons NOT to do this? > > > > > > _________________________________________________________________ > > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > > Web Interface: > > http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&t > ext_mode=& > lang=english > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Web Interface: > http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&t ext_mode=& lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
