Exchange 2003 volumes with SnapManager setup?

[marcconeley]

Hi,

I've read the SnapManager for Exchange Best Practices Guide (tr-3326.pdf) but I'd like some advice on my understanding of it before I go ahead with my Exchange/NetApp migration.

Our current Exchange2K3 environment is running on dedicated physical server, although we have just installed a new Exchange2K3 server on our VMware cluster which runs off a NFS volume on our NetApp. I now want to correctly configure our new Exchange server with SnapManager & move the databases to the NetApp before I start migrating our mailboxes to it from the old server (I figure it's easier & faster to do this with empy storage groups).

Our site currently contains around 150 users, and the total Storage Group size of all mailboxes is about 400Gb - so we're not talking 1000s of users and clustered Exchange - it's a relatively simple setup.

Now my problem: I want a simple, easy to manage volume setup that will alllow me to easily SnapMirror our Exchange data to our DR site (we already plan to SnapMirror our key VMs to our DR site which will include our new Exchange server).

We previously set this up in another site by creating a seperate volume for every Mailbox Store that we had, + 1 for all storage group log files, + 1 for our public folder store (this gave us 8-9 volumes to manage in total).

Is this overkill and can I/should I simply place all mailbox stores on the same volume? i.e.

- 1 volume for mailbox stores.

- 1 volume for logs.

- 1 volume for public folder store.

If anyone has any experience of deploying Exchange and SnapManager in a similarly small environment I'd really appreciate your views on this!

Regards,

Marc

[ianaforbes]

Hi Marc

There are several supported storage layouts for Exchange and it simply depends on your requirements. The Microsoft best practice is to place your databases in a new SG until all SG's have been used - then go back to the first SG and continue. With Exchange 2003 you have support for 4 SG's and 5 databases per SG. Exchange 2007 is 50 SG's and 50 databases per SG.

By following this architecture you're able to backup and restore individual databases if required. You might require different backup policies for senior management then the rest of the company and by separating your databases this way gives you that flexibility.

If you were to layout a single lun per SG that would mean that all of the databases in that LUN are backed up together AND (more importantly) reatored together. That would mean if you had one corupt database that you wanted to restore, you'd have to restore all of the databases in that LUN together.

Another thing to be aware of if alking about snapmirror replication is since snapmirror is performed per volume, all databases within a volume will get replicated together. If you require different databases to get replicated perhaps more frequently then others you would layout those database kun(s) on different volumes.

Lastly, snapvaulting your Exchange backups requires some thought in how your storage layout should look. Snapvault is done at the qtree level, and careful thought should be followed before architecting your storage for Exchange if you plan on doing snapvault archiving.

For a simple Exchange 2003 layout I'd use the following:

1 volume - Exchange databases lun(s) - including Public Folder

1 volume - Exchange transaction logs

1 volume  - SnapInfo directory

*The logs and snapinfo luns can both exist on the same volume.

Hope this helps.