We are currently doing some testing for SnapManager for Exchange configuration, running SME 6.0 with MS Exchange 2003 SP2. Does each and every Storage Group require its own LUN assignment? We’ve had a look in the SnapManager 6.0 for Microsoft Exchange Installation and Administration Guide and were not able to ascertain.
Is having multiple Storage Groups using the same LUN for their databases (mailbox stores) a supported configuration (see below)?
How you wish to do backups is really up to you. SME does enforce some configurations regarding separation and even then there are Exchange version changes.
The first thing I would say to you is that in your current plan as pictured you don't have any granularity of restore.
If you back up one store you have to back up all three. If you did need to restore one store you have to restore all three. That will take everyone offline for a while, not just the people in the affected store.
At the very, very least you would want three FlexVols & LUNs for your databases, even if you go with a single log LUN.
Run the SME configuration wizard. Anything that SME doesn't like will be flagged up there and you will be able to take note of what changes you need to make.
Sadly I don't have a 2003 box to spin up and do the configuration testing for you otherwise I'd have been able to tell you exactly what scenarios are permitted and what are banned. However, I strongly recommend that you don't implement as above but at least split the stores out into their own FlexVols.
Re: SnapManager for Exchange 6.0 for Microsoft Exchange 2003
This configuration should work, but like Mark said, your restore granularity is at the database LUN level.
What this means for the configuration you have depicted is that if you have to restore one database in the SG, the others will get restored as well. This will result in a disruption in service for all of the databases in the SG until the restore has completed.
It is a better to put your databases on their own LUNs and each DB LUN into their own flexvol, so that disruption in service is only isolated to users on the failed database.