Monday, November 2, 2009

Backup & Recovery in Exchange 2010

By: Rik Hoffelder
In my previous post, Cluster Databases Instead of Servers … Brilliant!, I covered several architecture changes to message store databases in Exchange 2010. Among those I noted that Database Availability Groups or DAGs add a new level of server resilience that can support same datacenter and/or remote site replication. So this begs the question, are backups really necessary? And to be honest I have to wonder that myself.
The answer really depends on the Exchange 2010 architecture you deploy and your requirements. Microsoft recommends that you maintain at least three database copies before considering the elimination of traditional backups. I am going to add that at least one of those three be in a remote datacenter and is configured as Lagged Mailbox Database Copy. This will help ensure that you can recover from database corruption resulting from controller or other such issues.

A lagged mailbox database copy will allow you to remove corrupt transaction logs before activating the copy to ensure that corruption is not replayed into the database. Keep in mind that a non-lagged mailbox database copy will have already played in the corruption also be unusable. It's the nature of the beast, in fact it affect ALL replication technologies which is why third party applications such as Double Take and NeverFail offer some form block rollback as part of their platforms. With Exchange 2010 there is no need to rollback, just remove the corrupt logs before activation.

(NOTE: Public Folder Store databases do not support continuous replication therefore you must either replicate each PF to another Exchange Server or maintain backups)

With this option do I still need backups? Well yes particularly if you budget will not allow you maintain at least three Exchange 2010 servers with at least on server offsite. If your business requires archival backups for legal or other reasons, you will need to continue maintain backups as usual even if you uses DAGs with multiple database copies. So what are my options? Has anything changed from my 2003 or 2007 backup processes? Yes, it has changed a bit. So before you begin the migration process you might want to make sure you are ready.

Streaming backup of message store databases are no longer supported in Exchange 2010. If this is your preferred or only backup method, you'll need to get with your backup software vendor for an upgrade and maybe some other changes. If you use a solution that supports the VSS APIs, you're in luck that's all Exchange 2010 supports. Exchange 2010 also provides integration with Windows 2008 Backup using the same WSBExchange.EXE process as was provided with Exchange 2007 SP2 which is adequate but has its limitations. (See Exchange 2007 SP2 is Here for more information).
Microsoft's System Center Data Protection Manager provides a robust platform to provide the capabilities missing from the Windows 2008 and Exchange 2010 in-box solutions. DPM along with other vendors such as Symantec, EMC, and IBM also allow you the ability to backup the passive copy of the database. This allows you to run backups more often with affecting user experience and server performance on the active copy.
Snapshot backups are also great solutions that have the lightest impact on overall performance. What's more they are extremely fast, usually less than 15 seconds, and several vendors offer value add by incorporating such things as brick-level mailbox restores from snapshot or snapshot replication. Snap Manager for Exchange from NetApp is an excellent example and one I am most familiar with, but that doesn't mean there are other great solutions. Just means I haven't worked with them yet.

The major reason for backing up your databases is so you can recover them in the event of a disaster. Exchange 2010 has a few changes there as well. Exchange 2007 introduced database portability, which allowed you forklift a database and transaction logs from one server to another in the same organization, run a few cmdlets to prepare and mount it, then redirect users to the new location.

Exchange supported what is known as dial-tone recovery for several versions. In fact I have done this in production environments as far back as Exchange 5.5 in 1997. Restoring the data in that situation was no picnic which is why Microsoft introduced the Recovery Storage Group in Exchange 2003. The RSG allowed you to "Dial-tone" and corrupt database (meaning delete it and bring up a blank DB) to get users working again while you restored the database from tape or disk to a recovery copy. At the end of the process, you would use the mailbox tools to merge the data from the recovery database into the production database. It was somewhat time consuming but a darn good process overall. RSGs were also a component of Exchange 2007 with improvements such as being able to recover deleted mailbox after the original user ID was deleted and merging the data into a different mailbox.

Exchange 2010 eliminates the Recovery Storage Group along with Storage Groups in general. This function is replaced by a Recovery Database. A recovery database is very similar in functionality and operation to a recovery storage group in several ways. First mail can't be sent to or from the RDB, it only supports the MAPI protocol and is only assessable by a special set of tools (Restore-Mailbox, Export-Mailbox). A RDB can only be restored to, it cannot be backed up, you can also restore to a RDB when the mailbox database is online. In fact if the mailbox database is mounted, the restore is automatically redirected to the RDB. Unlike Exchange 2003 you may only have one RDB mounted on a server at a time.

I should note that RDB creation and management is entirely Exchange Management Shell based. Unfortunately Microsoft chose to remove the GUI-based tools included in Exchange 2003 or 2007 in the RTM version of Exchange 2010. I hope they bring that back in SP1, this was a handy feature for my less Exchange savvy customers.

Thus far I have primarily focused on mailbox store database, to ensure full recoverability there other roles that must be accounted for. Any Exchange 2010 (2000 or later for that matter) must take Active Directory into account. All Exchange specific configuration data is stored in the Configuration partition of Active Directory. Therefore if you ever need to perform a complete rebuild of your Exchange environment, you must make sure you have a working copy of Active Directory. I specifically recommend backing up the System State at a minimum on at least one or two domain controllers in each domain of the forest at least once a day, every day. Exchange is also very heavily dependent on DNS. If you use Active Directory-integrated DNS simply backing up the System State of a DNS-enabled domain controller will take care of that. If you do not use AD-integrated DNS or a non-Microsoft platform for your DNS, follow the guidelines recommended by the vendor.

The items I would consider for backup on non-mailbox server roles include a full operating system backup, including server System State at least once a month (more than once a week is overkill) and anytime the operating system of applications have been changed, such as after patch Tuesday or when a rollup or service pack is applied to Exchange or other supporting application on the server. Now let's take a roll by roll look at what else to take into consideration.

Client Access Servers do not maintain user data, therefore the only major items to concern yourself with are keeping a backup copy of your certificates. In the event of a total loss of the server you would reset the computer object in Active Directory, then build a fresh operating system. When you install Exchange specify the /RecoverServer switch when running setup. This will read in the original configurations of that server from Active Directory. At this point you just need to import and enable the certificates. This will allow a complete recovery without data loss.

Hub Transport Servers do maintain a certain amount of user data in the form of messages in transit and the transport dumpster. Neither of these items can be backed up directly, but you can recover in-transit messages from a hub transport server provided you can get to the disks. Exchange 2007 and 2010 hub transport servers use an ESE database, as opposed to IIS SMTP queues used in 2000 and 2003. Because of this and database portability you can copy the ESE file and logs to another hub transport server then recover the database using ESEUTIL and deliver the messages. This also holds true for Edge Transport Servers. Much like the Client Access Server recovery, the total loss of a hub transport server requires resetting the computer object, installing a fresh OS, and running Exchange Setup with the /RecoverServer switch. If you have Edge Transport Servers you will also need to reconfigure your Edge Sync policies.

The Edge Transport server behaves much like the hub transport in recovery scenarios. The ability to move the ESE database to redeliver messages is also an option here. You should also make sure you backup the Edge server setting using the ExportEdgeConfig.PS1 script included in the Scripts directory and store the output in a safe place. In the event of a total server loss you would build a new workgroup server, install the Edge Transport role, the run the ImportEdgeConfig.PS1 script to return to a pre-failure state.


More information on Exchange


13 comments:

  1. For the recovery of Exchange 2010 database, here is a good tool to recover the complete data quickly and accurately by rebuilding the damaged items in Exchange databases: http://www.serversdatarecovery.com/exchange.html

    ReplyDelete
    Replies
    1. Thanks Sean for sharing the information about this advance tool. It did a great job in our case and it successfully rebuild our Exchange 2010 store databases.

      Delete
  2. There are many inbuilt applications available on Exchange sever for recovery of corrupted mail box but this process is bit difficult for a lay man as it requires technical expert. Because all the process depends on command lines. To overcome such issue many companies developed a software for repairing, recovering and conversion of your exchange server database. One such utility is here with user friendly interface thus you can operate it easily without any technical support.
    http://www.exchangeedb.pcrecoverytools.com/

    ReplyDelete
  3. One of the best and most trusted exchange server tool to fix all database corruption issues in MS Exchange Server, can be downloaded from here: http://www.recover-computerdata.com/exchange-server-recovery.html

    This Exchange recovery tool has been designed to scan entire database files, to recover lost data and extract all inaccessible items from it. The software has been also incorporated with rich and interactive graphical user interface to offer easy and quick recovery of lost or damaged data.

    A free trial version is also available!

    ReplyDelete
  4. Nice article !
    Thanks for sharing this.
    However, I have also explored another informative article resource http://www.petri.co.il/edbtopst.htm which is capable in dealing with all exchange server related issues in minimum time taken. One can find complete exchange disaster recovery solution, backup restoration solution as well.

    ReplyDelete
  5. Thanks Rik for the step by step procedure to restore Exchange 2010 Server database. There are also some third party Exchange database recovery applications available in the market which helps the users to repair and recover the damaged database quickly and in just few steps. These tools has been developed with easy to use GUI and do not require technical skills to operate. One such tool that worked in our case is here: http://www.edbtopst-converter.com/exchange-recovery.html

    Hope this tool will also work who are unable to perform recovery with the help of above said steps by.

    ReplyDelete
  6. Use EDB exporter tool to recover Exchange of all versions if it becomes inaccessible due to any reason. EDB to PST converter program is successful in each situation of Exchange corruption and gives assurance of winning conversion of EDB into PST Outlook. It is a marvelous application easily transfer EDB to PST without any alteration in Exchange data.

    http://www.recoverpublicfolderedb.exchangedatabaserecovery.biz/

    ReplyDelete
  7. Hello,
    You can use another effective and more affordable application for Exchange Recovery from here http://www.restoreexchangeserver.com . By using this software, which is well known as Kernel for Exchange Server Recovery you can easily repair and convert damaged EDB files to PST files.

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete
  9. Try Exchange Database Recovery (EDD ) tool and repair and recover corrupted or damaged edb file. After recovery software converts it to PST file format which is then easily usable with the MS Outlook application. For more information and free download visit here
    http://exchange-server-recovery-tool.blogspot.com
    http://mailboxexchangerecoverytool.blogspot.com

    ReplyDelete
  10. Exchange issues without facing any interference. It is the relevant and result-oriented solution to get back crucial Exchange database.

    Get More info:http://www.filesrecoverytools.com/edb-to-pst-converter.html

    ReplyDelete
  11. Easily repair Exchange EDB mailbox database with best Exchange mailbox repair software. It is better to opt Exchange server recovery program to fix EDB errors and read EDB file data. MS Exchange EDB export to PST utility is effective to open Exchange database in Outlook PST file format within less time.

    Read More :- http://www.exchange-edb.recoverydeletedfiles.com/

    ReplyDelete
  12. With the support of RecoveryFix for Exchange Server Recovery Tool. It can easy to recover emails, attachments, contacts, calendars, tasks, etc. from corrupt EDB files. It can supported all update version of MS Exchange Server 2013 / 2010 / 2007 / 2003 / 2000 and 5.5. Visit here - http://www.recovery.exchangeedbtopst.net

    ReplyDelete

Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.