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
Read more!
