Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Slow Exchange 2003 Mailbox on v7 sp4a 1

Status
Not open for further replies.

ArmchairJedi

Technical User
Nov 10, 2004
23
0
0
AU
G’day,
We’re experiencing very slow mailbox level backups on our v7 Commserve. We’re getting under 2gb/hr throughput which is pretty ordinary. It’s been going slow for a long time but i just haven’t gotten around to investigating.... till now. Is there a best practices type doco on using commvault with exchange 2003 for mailbox backups?

Our exchange is running on 2 nodes of an MSA 1000, we have 3 storage groups on each server, each one is between 70gb and 110gb. The database backups take approx 6 hours each but the mailbox ones take up to 30 hours for a full and some incrementals even take that long.

I think it’s the exchange and my manager thinks its CommVault so what I really need to know is what to look at performance wise to locate the problem... any ideas?


Armchair Jedi ~ So dense light bends around him ;-)
 
Inherently, Microsoft Exchange mailbox backups are slower than database backups. This is due to the fact that, in order to back up mailboxes on a 'brick-level,' Commvault has to impersonate an Exchange mailbox account and authenticate for each individual mailbox item, whereas a database backup is streamed to Backup Exec in one continuous data package.

This means it is limited by the MAPI limitations {microsoft} where one of these is small bandwidth pipe.
The good news is this is on a stream level so I would recomment breaking up your backups into several streams eg, 1 for each store or A-K etc and run them at the same time I do this for customers and it greatly reduces the backup time.
Each server has its own sweet spot for the number of streams to run together I have some running 6 and some up to 20 start low and creep up unit is either slows or doesnt change any more

Hope this helps
rgds rod
 
Thanks for the info, Commvault support have advise similar methods.

Now i'm wondering if i'm better off to set up filters A-C, D-f etc or just break it up by storage group/database.

For example our 12000 mailboxes run on 2 servers
each server has 3 storage groups
and each storage group has 3-4 databases

Currently each server backs up based on the 3 storage groups... giving me 3 jobs from each server.

I'm a bit torn between dispersing the subclient content across multiple area's by filtering vs keeping each of the sg/db's in one subclient entity each (which will give me about 11 smaller subclients/jobs for each server).

Opinions?... either method will probably speed up the jobs.


Armchair Jedi ~ So dense light bends around him ;-)
 
Based on the above figures, DB based subclients is not a bad way to start and if you find that this is still not enough you can look at breaking it up further.
The "filters" way using auto-discovery is also a fairly easy to set up if you do need to break them up further down the track but always good to keep it simple and see how it goes.
I recommend the DB way and gauge how that works for your backup window before having to break them up further as auto-discovery is great if you know in what groupings to break them into so that the load is well balanced.

hope this helps
rgds rod
 
Hmm... i've done as planned and created a bunch of subclients based on the actual storage group databases. I took each one, created the new subclients and renamed the last one (the original one) to reflect the change). When i look at the discovery tab i can see all the subclienst aimed at the storage groups... nice and neat.... but for some reason they are failing to actually associate the mailbox's with the new subclients. The original 3 main ones (now renamed and re-aimed) still think they own all the mailboxes...

Should i be using storage group affinity or match mailboxes based on regular expressions?

I can't really delete the original 3 subclients cos that will break my history...

Armchair Jedi ~ So dense light bends around him ;-)
 
Since they have already been assigned via previous backup/discovery you have to manually move them, new mailboxes will be put correctly in the right subclient.

From each subclient add the clients via discovery you want in that subclient (even though you can change it to say other sub clients when you leave the window sometimes it only changes content for that subclient).
rgds rod
 
We have about 6000 users on each exchange - manualy doing anything isn't really an option.

What i did was create a new test subclient and assigned EVERYTHING to it.. ran a backup so it'd do the discovery... stopped and killed it and then deleted it. Upon running my next backup it re-discovered the mailboxes (cos the test one no longer existed) using the storage group affinity and put them in the right place. so far it appears to be working ;-)

Armchair Jedi ~ So dense light bends around him ;-)
 
Classic, hadn't thought of doing that before, I'll keep that in mind for other customers :)
Rod
 
Hmm.. NOTE!

If you run the full backup of your TEMPORARY subclient in order to do the discovery reset trick... make sure you leave it going until its starts to write to media. You haveto let it copmlete the scan completely becore you stop and delete the temproary subclient and re-do the discovery.

Armchair Jedi ~ So dense light bends around him ;-)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top