Its a Guest Post
There are several ways Exchange 2010 administrators can protect their users’ critical data, and a mix of approaches may be the best way to do this, depending upon your users’ needs. You can create Database Availability Groups (DAGs) to ensure that that mail remains available even if you suffer a server failure. You can span a WAN with a DAG to keep mail available even if you have a data Center outage. You can implement Exchange archiving to capture a copy of every email message that goes in or out of your environment to ensure you have a copy. You can create regular backups and store the tapes offsite to ensure you can restore content even after a user has accidentally deleted something critical. In this post we are going to take a look at how to create a recovery database in Exchange Server 2010 so that you can recover data from a backup in the event something happens.
Recovery databases are similar to other Exchange mailbox databases in that they require storage, will have both database and log files, and will consume the same amount of space for the same amount of data. However, that is where the similarities end. How recovery databases differ is important to understand.
1. A recovery database doesn’t count against any maximum number of databases your license entitles you to, so if you are using Exchange 2010 Standard, you can still have your five mailbox databases plus one recovery database.
2. You can only have one recovery database per server.
3. Client connections are blocked to recovery databases. You can mount a database and access mailboxes using MAPI based tools, but no client can connect.
4. Recovery databases aren’t treated like other mailbox databases. You cannot enable circular logging, retention policies are not applied, and you cannot run online maintenance.
5. ACLs are not maintained when you restore data to a recovery database. You get the content, but not the permissions.
You should also note that recovery databases are intended only to restore mailbox data. Public folder content cannot be recovered to a recovery database. You can recover data from the regular mailbox database or databases used for Exchange archiving, but not for public folders.
When you create a recovery database, consider that even with the limitations above, it is still an Exchange database. It will have a database file and also log files, and the I/O demands will be similar. You will also want to ensure that the volumes you use for the database and the log files have more free space than the largest mailbox database you may need to recover, as it will be a waste of time to start a recovery only to find you don’t have enough space to restore the backup database.
When you are ready to begin, open an Exchange Management Shell and run the following command, where you specify the full path for both the database and log files (different volumes are recommended) and you use the –recovery keyword to designate this as a recovery database:
New-MailboxDatabase –recovery –name “Recovery Database” –server MBXServer01
-edbfilepath d:\exchange\databases\ -logfolderpath l:\exchange\logfiles\ [enter]
While you can have multiple recovery databases in your Exchange organization, remember that you can have only one per server. Ensuring that the volume has enough space to accommodate the largest mailbox database you may need to recover will help speed those operations along, so consider reserving space on the fastest mailbox server you have so that if you do need to perform a recovery, you can do so as quickly as possible.
To enhance your backup and recovery plans, you should also implement Exchange archiving for users. You can copy all messages to the archive, or use DAGs to provide high availability to the most recent mail and provide each user with access to Exchange archiving to store messages that are older. Retention policies can move data from the primary mailbox to the Exchange archive as needed, so you get the best mix of high availability for the newest content, and you can use backups to ensure content store in Exchange archiving is safe as well.
This guest post was provided by Casper Manes on behalf of GFI Software Ltd. Read more on how to improve your Exchange archiving.
All product and company names herein may be trademarks of their respective owners.
