Data Protection for Exchange Server 2010

Written by Paul Cunningham on July 1, 2010

chuteThere has been a lot of buzz created about Exchange Server 2010’s new database capabilities.  The terms “RAID-less” and “backup-less” get mentioned in conversations but are often taken out of context, or used with incorrect assumptions.

But why are people so excited about Exchange Server 2010 and talking about throwing out RAID and backups?  There are three main reasons for this.

Three Big Exchange Server 2010 Improvements

Improved Database Performance – the Exchange database schema has been overhauled to deliver much greater efficiency and therefore much better performance in terms of disk I/O.  This overhaul stirred some controversy because it put an end to single instance storage, however the small loss of SIS delivers much greater benefits in performance.

Improved High Availability – Exchange Server 2007 had four different HA/DR options, each one with its own complexities and limitations, and each one administered in a different way.  Exchange Server 2010 simplifies this to one single, vastly more effective high availability model called Database Availability Groups.  This basically involves replicating a database between as many as 16 servers (DAG members) that can seamlessly fail over if any individual server experiences a fault.

Improved Data Retention – In Exchange Server 2010 mailboxes and databases can be much bigger than previous versions, archiving has been built in, and longer retention is feasible making recovery of single items and mailboxes possible over longer periods without having to access backups.

These improvements have led to the idea that an organization can deploy multiple Exchange servers in a DAG using cheaper, slower storage sub-systems, without RAID to replicate the data, and without backing up because emails can be recovered almost indefinitely.

Which is true, but only if Exchange Server 2010 is deployed correctly with enough resources to make this possible.

Going RAID-Less for Exchange Server 2010

RAID-less mailbox servers is not recommended if you have not deployed at least three DAG members, so that there are at least three copies of each database.

Other server roles would naturally be protected by RAID for their operating system volumes, although you could go RAID-less for these as well provided there are more than one of each role deployed in a redundant configuration.

Going Backup-Less for Exchange Server 2010

A backup-less Exchange Server 2010 environment is more complex than some people seem to assume.  For a backup-less environment to be feasible you must:

  • Have at least three DAG members across two physical locations
  • Have at least one lagged database copy (this is a copy that “lags” behind at a set interval before committing replication data to the database)
  • Have circular logging enabled for all of the databases
  • Have your archive and retention settings fully implemented and optimized to prevent permanent deletion of data
  • Have your Role-Based Access Control fully locked down to prevent inexperienced administrators from destroying the DAG itself through error or malicious intent
  • Not be using Public Folders (which are not protected by DAGs)

Obviously that all becomes complex in its own right, not to mention potentially very expensive.  Multiple physical locations means more datacentre costs, and the number of DAG members increases the number of expensive Enterprise Edition licenses required for Windows Server 2008.

Even with all of the complexities understood and the expenses affordable for an organization, there still remains some risk of complete loss of email data through a disaster.  With that in mind it is more feasible that a less complex DAG deployment can simply be used to reduce the frequency of backups, rather than eliminate them entirely.

In summary, RAID-less Exchange servers may become common over time, but the idea of backup-less Exchange is unlikely to gain any real traction in production deployments.

Subscribe to my RSS feed

Leave a Comment

Comment Policy