In my recent post I examined the question of whether Exchange Server 2010’s new replication and retention features could mean an organization no longer needed to back up their Exchange servers.

One reader emailed me to suggest that avoiding backups would be unwise, citing the example of potential corruption within the database that might replicate to all copies within the Database Availability Group and cause loss of data.

The scenario is one that definitely needs to be considered.  Although Exchange Server 2010 includes application intelligence to detect and handle some database corruption scenarios, there still exists the possibility of logical corruption leading to data loss.

Fortunately the solution to this problem is already included in the DAG feature of Exchange Server 2010.

If you are already familiar with Exchange Server 2007 Standby Continuous Replication then you already understand the concept of replay lag time.  Replay lag time is a configurable setting on each database copy within a DAG that delays the replay of a transaction log into that database replica.  A database copy with a replay lag time of more than zero is referred to as a lagged copy.

For example, within a DAG there may be 3 servers hosting replicas of Database 1.  Two of the servers are located in a primary data center, and the third server is located at a secondary data center.

The servers at the primary data center are configured with a replay lag time of zero, meaning the passive copy of the database is kept up to date with the latest transaction log information in near real-time.  A failure of one server permits seamless failover to the second server and continued email operation for the business. Continue reading What if You Never Backed Up Your Exchange Server Again? (Part 2)

Imagine for a moment that you never had to back up your Exchange servers again.  Sounds crazy right?  Well with Exchange Server 2010, it may not be as crazy as you think.

In a recent post I described the killer new High Availability feature of Exchange Server 2010 – the Database Availability Group (or DAG for short).

A DAG is an Organization-level object that allows a database to have several passive replicas on other servers (DAG members).  When a DAG is configured it permits individual mailbox databases to failover to passive instances should any problem with the active database arise.

The nature of DAGs means that they can be deployed to protect from failures at almost any layer of the Exchange infrastructure.  DAGs can protect from anything from a single failed server hard disk to an entire data center failure as long as the DAG is architected accordingly.

How this relates to backups is simply this – if a database is protected from all failure scenarios by the DAG, why would you need to back it up at all?  Let’s take a closer look at this question. Continue reading What if You Never Backed Up Your Exchange Server Again?

I recently wrote a five part series about Exchange Server 2007 high availability, describing each of the HA features (LCR, SCC, CCR, and SCR) in detail and demonstrating their uses, strengths and weaknesses.

With the release of Exchange Server 2010 these high availability features are no longer available.  The features have now been replaced by a single high availability option known as Database Availability Groups (or DAGs for short, admittedly a horrible acronym for what is truly the product’s finest feature).

A little background is required to fully understand the evolution of Exchange storage architecture to its current incarnation in DAGs.  Going back to Exchange Server 2003 the product was limited to a maximum of 4 Storage Groups, each containing a maximum of 5 databases.  This meant a maximum of 20 databases (of either Mailbox or Public Folder type) per Exchange server.

Exchange Server 2007 improved on this in two ways.  Firstly, the product was limited to 5 Storage Groups and 5 databases for the Standard Edition, and up to 50 Storage Groups and databases for the Enterprise Edition.  The best practice with Exchange Server 2007 was to use one Storage Group per database, unlike Exchange Server 2003.

Naturally this lead to the question of why have Storage Groups at all?  Exchange Server 2010 answers this question by doing away with the concept of Storage Groups entirely.  Databases are now Organization-level objects that contain both the transaction logs and the database itself.

Exchange Server 2010 then introduces the Database Availability Group to provide high availability.  A DAG is a group of Mailbox Servers (up to 16 per DAG) that replicate databases and perform automatic failover and recovery for either individual database or entire server failures.

So how does this compare to Exchange Server 2007 high availability?  An immediate advantage is that DAGs unify Exchange high availability into a single feature and management toolset, unlike Exchange Server 2007 which had 4 different features each managed with different tools.

Let’s take a more detailed look at each of the features to see how they compare to DAGs. Continue reading Exchange Server 2010 Delivers Improved Availability

In my last posts I discussed Exchange Server 2007 Single Copy Clusters, which is one of two clustering features available in Exchange.  In this post I will discuss the other type of Exchange Server 2007 clustering, Cluster Continuous Replication

What is Cluster Continuous Replication?

Cluster Continuous Replication (CCR) for Exchange Server 2007 would not be familiar to anyone who only has clustering experience with previous versions of Exchange.  In a CCR cluster two cluster server nodes connect to non-shared resources in an active/passive configuration.  Exchange storage group and mailbox database information is replicated between the active and passive node using asynchronous log shipping.  I explained asynchronous log shipping in the first part of this series on the basic concepts of Exchange Server 2007 high availability.  The same log shipping occurs in Local Continuous Replication.

The two CCR cluster nodes appear to other computers to be a single system, and when one server node fails the clustered resources are able to fail over to the other node and continue operation.

CCR provides high availability for the Mailbox Server by protecting it from the failure of either cluster server node, as well as protecting it from storage failure.  Because each cluster node is connected to its own non-shared storage, the failure of one does not impact the other.  This also means that CCR disk storage can consist of much cheaper hardware alternatives than an enterprise-grade SAN would cost, making Exchange high availability a reality for businesses with smaller budgets. Continue reading Exchange Server 2007 High Availability Part 4 – Cluster Continuous Replication

In my recent posts I discussed the fundamentals of Exchange Server 2007 high availability and how to use Local Continuous Replication.  In this post I will demonstrate one of the two Exchange Server 2007 clustering methods, Single Copy Clusters.

What are Single Copy Clusters?

Single Copy Clusters (SCC) for Exchange Server 2007 is basically the same as clustering in previous versions of Exchange Server.  Two cluster server nodes connect to shared resources in an active/passive configuration.  The two servers appear to other computers to be a single system, and when one server node fails the clustered resources are able to fail over to the other node and continue operation.

SCC provides high availability for the Mailbox Server by protecting it from the failure of either cluster server node.  Typically the cluster will also consist of redundant networking (e.g. teamed network interfaces, multiple switches) and storage components (e.g. a SAN that is in itself a highly available system through redundant components).  The servers are also usually located in high quality data centers with redundant power and cooling.

SCC is available in the Enterprise edition of Exchange Server 2007.  Because it uses an underlying Windows Server failover cluster, the servers that form part of the cluster must also run the Enterprise edition of Windows Server (either 2003 or 2008).

Unlike LCR an SCC cluster offers high availability benefits but no performance benefits.  Because there is a single copy of each mailbox database within the cluster there is no opportunity to use a passive copy for backup operations.

How to Install a Single Copy Cluster

In this example two Windows Server 2003 Enterprise edition servers have been configured with the basic requirements of a failover cluster:

• A public network interface for normal network operations
• A private network interface for the cluster “heartbeat”
• Shared disk storage for the database, log files, and cluster quorum disk

Once the failover cluster has been configured we can install Exchange Server 2007 on the first node.  Run setup as normal, and when selecting the roles to install choose “Active Clustered Mailbox Role” as the server role.  You will notice that a clustered mailbox server cannot co-exist with any other server role. Continue reading Exchange Server 2007 High Availability Part 3 – Single Copy Clusters

In my last post I explained the basic concepts of Exchange Server 2007 high availability.  In this post I will demonstrate one of the Exchange Server 2007 HA features that is called Local Continuous Replication.

What is Local Continuous Replication?

Local Continuous Replication (LCR) uses asynchronous log shipping technology to maintain a copy of a mailbox database on another locally connected disk volume.

For example, the mailbox database and transaction logs may reside on fast, expensive SAN disks, but the LCR copy is kept on slower, cheaper SATA disks.

LCR provides high availability for the Mailbox Server by protecting it from a storage failure.  If the SAN disks failed or became disconnected for some reason the server could continue serving end users via the replica database, possibly at a degraded performance level if the slower disks were not able to handle the required I/O load.

Because LCR is available in both Standard and Enterprise editions of Exchange Server 2007 it is a fairly easy way to achieve some high availability for the server. Continue reading Exchange Server 2007 High Availability Part 2 – Local Continuous Replication

Microsoft Exchange Server 2007 has several different Mailbox Server high availability features included with the product.  Each of the features is similar to the others in some ways but also very different.

In this post I will explain each of the high availability features and which types of scenarios they are suitable for.

What is High Availability?

High availability is a term used to describe the avoidance of unplanned downtime for a computer system through the implementation of hardware and/or software solutions.  Generally speaking a high availability solution will involve the elimination of and single points of failure in the system, often by duplicating or replicating components of the system so that if one fails the other is able to continue performing the role.

An example of downtime would be an email server that has suffered a hard disk crash and is unavailable to users who are then unable to send or receive email.  An example of a high availability solution in this case would be the use of a RAID volume to protect from single disk failures. Continue reading Exchange Server 2007 High Availability Part 1 – HA Fundamentals