Many Exchange Server admins have learned the hard way that high availability does not equal disaster recovery....
Administrators must understand the difference between the two and know which disaster recovery tools are native to Exchange Server.
Most admins are familiar with high availability (HA) strategies for Exchange and other servers. Clustering and replication across zones provide high availability of an Exchange server and its data. The nodes work together to meet load demands, and if a node goes offline -- for patching or a data center emergency -- the other nodes should carry the load until the node returns. This approach is called an HA strategy.
The problem is that these procedures typically address the issue of serving client applications, but aren't concerned with data integrity. If the IT department has an HA strategy but no backups, then end users receive bad data -- served in a very reliable manner. The server isn't down, but without a disaster recovery (DR) strategy, it's difficult to get important data back.
DR is the art of ensuring that the IT department can restore critical information after it discovers data corruption or if a cataclysmic event knocks out all active nodes in a data center.
Exchange native data protection
Exchange Native Data Protection uses Database Availability Group replication and relies on multiple Exchange Servers in a clustered arrangement. Using cluster nodes in geographically distant data centers and other features in Exchange Native Data Protection helps protect data and should work well enough to encourage IT to drop traditional backups.
Managing lagged database copies
In an Exchange Database Availability Group, administrators can create a database copy after a delay. A lagged copy is useful when an end user accidentally deletes things; it can also be used to recover from a logical database corruption before it replicates to the other copies in the group. Instead of taking a series of point-in-time backups, the system continuously maintains a pre-restored backup that is a certain interval behind the live environment.
The administrator sets the delay period. Ideally, the lag time is long enough to detect serious issues but not so short that critical data is lost before corruption or before the deletion is detected. This lagged copy feature can be very helpful and faster than regular backups, but relying on it to replace backups can be dangerous if you don't use a monitoring system to catch issues early. Encourage users to report these kinds of errors quickly so it can be fixed before the lag period ends and the deletion spreads to the lagged copy.
The administrator can activate the lagged copy of the database with PowerShell and then use the New-MailboxRestoreRequest cmdlet to restore data from the activated backup into the live database. Administrators can either restore the live database with the lagged copy or select data and put it into the live Exchange environment.
Exchange 2010 vs. Exchange 2013 feature faceoff
How well do you know the difference between the key Exchange 2010 and Exchange 2013 features? Test yourself with this 10-question quiz.
Recovering deleted items
Exchange has a number of features to hold and recover items that were deleted either by accident or on purpose.
Administrators can apply a policy to the Recoverable Items folder; deleted items will go in this folder first for a specified amount of time. Administrators can use the folder to speed a recovery process and avoid the need to restore a database. Microsoft offers more details about this folder and other retention features here.
Traditional backups have a place
Routine backups are still a valid recovery choice and could be important in a DR strategy. But creating those backups may not be as simple as pointing a file copy utility at the database files.
Exchange 2013 only supports backups made using an Exchange-aware Volume Shadow Copy Service-based utility. Exchange features a plug-in for Windows Server Backup, but there are a number of issues around creating proper backups.
The complete guide to Exchange Server backup and recovery
Exchange Server transaction logs impact data recovery
How to test VSS-based backups for Exchange