There 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.

Data Protection for Exchange Server 2010

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

One of the least exciting yet most important parts of an Exchange administrator’s job is making sure that the Exchange Server environment is properly backed up.  Throughout my career I’ve spent many long nights with customers who have suffered a failure of an Exchange server and discovered that their backups are unreliable or even non-existent.  In this series I will discuss Exchange Server 2007 backup and recovery and demonstrate some actual disaster recovery scenarios that I have encountered on the job.

What to Back Up on Exchange Server 2007

To understand what to back up in an Exchange Server 2007 environment you must first consider the server roles that you have deployed.  In the most basic Exchange Server 2007 deployment the Client Access, Hub Transport, and Mailbox server roles are installed.  In more complex environments more than one of each of those roles might be deployed, the Mailbox server might also be clustered for high availability, and other roles such as Edge Transport and Unified Messaging might also be in use.

In addition to the Exchange server roles there are also considerations such as the Active Directory (a pre-requisite of any Exchange environment), client data such as PST files or POP3 mailboxes, and any server-based anti-spam system that is deployed.

All Exchange Servers

Generally speaking all Exchange servers in an organisation should have their local file systems and System State data backed up.  However because Exchange Server 2007 stores much of its configuration in Active Directory you can recover some server roles without needing to have backed up any data at all.

For example, if a Hub Transport server crashes and is unrecoverable the Exchange administrators can build a new server of the same name, and then install Exchange Server 2007 on it with the /m:recoverserver setup parameter.  This tells the installation to use the configuration stored in Active Directory for the server being rebuilt.

Despite this feature there are still several items to be aware of for Exchange Server 2007 backups.

Mailbox Servers

The most obvious role that an organisation will backup is the Mailbox server role.  As the name suggests this role hosts all of the mailbox databases and public folder databases.  Because of the database format in use, backups must be performed using an Exchange-aware backup product.  These products can use one of two different methods to backup the database.

Streaming Backup – this backup “streams” data directly from the live database page by page.  The built-in Backup utility for Windows Server 2003 performs this type of backup of Exchange.  Remote streaming backups are disabled by default in Exchange Server 2007 Service Pack 1 but can be re-enabled with a registry change.

Shadow Backup – a VSS shadow copy (or snapshot) of the database is made so that a “point in time” backup can be performed.  Most third party backup products perform this type of Exchange backup.

For Mailbox servers with database replication enabled (either Local Continuous Replication, or Cluster Continuous Replication) an Exchange-aware backup product can usually perform its backups using the “passive” copy of each database.  This is an advantage in many environments because the entire backup I/O load is kept off the active database, preventing any performance impact on end users.  This makes it possible to perform backups during business hours, which is important to some organisations.

Hub Transport Servers

Although most of the Hub Transport configuration is stored in Active Directory the local file system still contains important data such as the message queues, log files, and some configuration files that are often modified by administrators for performance tuning.

By including the C:\Program Files\Microsoft\Exchange Server\TransportRoles folder (and all sub-folders) in the backups you provide some protection from failure, however the queues and logs change on a minute by minute basis so unless you run multiple backups through the day the recovery benefits are minor.  Additionally, these files are often locked and in use at all times so the backup must be performed by a product that can handle locked files correctly.

Client Access Servers

Most of the important configuration information for Client Access servers is not stored in Active Directory, but rather is located on the local file system of the server and also the IIS metabase.  The IIS metabase in particular contains vital information such as customised settings on the Exchange virtual directories.

To backup these important items you should include the C:\Program Files\Microsoft\Exchange\ClientAccess folder and the System State of the server in your backups.

Edge Transport Servers

Edge Transport servers are not members of any Active Directory domain, so cannot be restored using /m:recoverserver.  Instead their configuration must be exported using the ExportEdgeConfig.ps1 PowerShell script, and the export file then backed up elsewhere.

In addition, the message queues and log files should be backed up in the same manner as with Hub Transport servers.

Unified Messaging Servers

Most of the configuration for Unified Messaging servers is stored in Active Directory, but as with other server roles some customisations are only stored on the local file system of the server.  The C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging folder should be included in backups.

Active Directory

Exchange Server 2007 relies on Active Directory and uses it to store most of its server configuration information.  The Active Directory database is backed up by including the System State of one or more Domain Controllers in backups.

Client Data

Although organisations are moving away from the use of PST files for email storage some still persist in using them.  PST files can be difficult to back up because the Outlook client will lock them “in use” and prevent some backup software from successfully backing them up.  Furthermore, if the PST file is stored on an end user machine it probably will not be included in server backups.

I have seen this dealt with in several ways, such as storing PST files on a file server share and using backup software that can handle locked files.  In many organisations though they simply consider PST files as being excluded from backups and accept any data loss that may occur from them.

POP3 clients are fairly rare in Exchange Server 2007 environments but the simplest approach with these is to configure the POP3 client to leave copies of mail items on the server so that the Mailbox Server backups can protect them.

Other Messaging Systems

To ensure that the entire messaging environment is backed up you should also consider any other non-Exchange servers that are involved, such as an anti-spam server.  In most cases this will mean backing up the file system of the anti-spam server, as well as any SQL databases it uses for storing quarantined items and reporting data.

How to Backup and Restore a Mailbox Server

In the next part of this series I will walk through the process of backing up a Mailbox server, simulating a failure, and then performing a recovery of the server and its databases.

Exchange Server 2007 Backup and Recovery Part 1 – What Needs to be Backed Up?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators