snapmanager for exchange 2010

[ Edited ]


I have an exchange 2010 server where we would like to use snapmanager for exchange.

Unfortunatelly we can't configure it because it saying the databases are in invalid state.

With 2003 it used to work that all of our DB's were on the same LUN also their respective log folder were on another lun.

Do I understand this correctly and in 2010 I have to create a LUN for each database ?

I would appriciate some insights or a pointer where did I get sidetracked.



snapmanager for exchange 2010


Ideally we recommend separating Exchange database and transaction log files onto separate LUNs and separate volumes whenever possible. This allows greater flexibility for backup and recovery procedures as well as data protection strategies

One lun per database

  • Single LUN per database architecture means that both the database and its corresponding log files are placed on the same LUN. In order to use this LUN configuration, mailbox databases must be part of a database availability group (DAG) that has two or more copies and does not use a hardware-based Volume Shadow Copy Service (VSS) solution.
  • Deploying LUNs in this configuration simplifies storage administration because there are fewer LUNs to manage; however, it also limits the ability to perform hardware-based VSS backup and restore procedure

Two luns per database

  • In this solution, each mailbox database and transaction log set is placed on a separate LUN. This solution provides greater flexibility in terms of recovery options but increases the total number of LUNs required
  • In environments with high LUN counts, transaction logs for multiple mailbox databases can be placed on a single LUN. In this situation, each transaction log LUN should be placed on a separate volume to provide the best RPO/RTO times. When deploying LUNs in this fashion, NetApp recommends limiting the number of log streams per LUN to from five through 10.

Hope this clarifies.



snapmanager for exchange 2010


Thank you for the answer. Of course we want to keep the DB's and the LOG's on a separate LUN, but my question was rather if I can put all my DB's on the same LUN in exchange 2010 ? because in exchange 2007 I know you could.



snapmanager for exchange 2010

Hi Peter,

Microsoft's Exchange Server 2010 eliminated the concept of Storage Groups.  They simplified the terminology such that now what we think of as a "storage group" can contain only 1 database and 1 corresponding log set. 

In the NetApp world, we indeed had the capability to back up and restore multiple databases stored on a single LUN provided they were all in the same "storage group" and shared one log set.  

Now that we can only have 1 database per log set in Exchange 2010 (what we used to call a storage group), we are indeed limited to one database per LUN.  This is due to the fact that what we were doing in prior versions of exchange when restoring a database was:

1) Restore all databases on the LUN...

2) Replay the logs for each database in the storage group forward from a single coordinated log set across all those databases in the same storage group.  

When using CCR in 2007, the same limitation (1 DB per storage group) existed that exists now in Exchange 2010.   The restriction is really centered around keeping the continuous replication engine simple and VSS friendly, while ensuring that log replay is reliable on all copies.  Exchange 2010 fully marries us to that concept wheras Exchage 2003-2007 still supported multiple DBs per LUN in the same storage group so long as you were not using any continuous replication (log shipping) technology. 

So, the bad news is that you do need one LUN per database.  The good news is that you can share a log LUN across many databases if LUN count is an issue (usually recommended to keep this to less than 5 log sets per LUN).  Wherever possible, I recommend that you use massive databases (up to 2 TB is comfortably recommended by MS), and have 1 lun for each database plus 1 lun for each log.   If you have to compromise, use multiple logs sets per LUN and you will still be in a supported config.