For administrators coming from an Exchange Server
2003 or Exchange Server 2007 environment looking to upgrade to Exchange
Server 2010, it may prove useful to compare and contrast Database
Availability Groups to existing replication technologies that one might
already be familiar with.
In Exchange Server 2003,
the only clustering option available was Single Copy Cluster. Exchange
Server 2003 could withstand a hardware failure of a mailbox server
because another node in the cluster could take over the identity and
host the Exchange Virtual Server. DAG provides a similar ability to
recover from a failed server though it does so without the need for a
shared identity or for shared storage.
Exchange Server 2007
brought about the concept of Clustered Continuous Replication which,
like SCC, provided protection against the failure of a server. It did so
by sharing the identity between two hosts. It surpassed SCC by
providing two copies of the Exchange Server mailbox database, which
protected Exchange Server from a storage failure or a database
corruption. DAG utilizes the same log shipping and replay process that
was introduced by CCR to perform its replication of mailbox databases.
Many of the same concepts such as Suspend-StorageGroupCopy and
Update-StorageGroupCopy are still present and accomplish essentially the
same tasks. The names have been updated to reflect the fact that the
storage group is no longer the root of the replication but instead it
occurs at the database layer. As readers may recall, storage groups no
longer exist in Exchange Server 2010 as the databases belong to the
Database Availability Group or to the Exchange Organization.
Administrators with experience in maintaining a CCR environment will
likely have an easy transition to DAGs.
Exchange Server
2007 also offered Standby Continuous Replication, which while similar to
CCR, didn’t utilize a shared identity. It used the same log shipping
and replay technologies to keep a remote Exchange Server 2007 in sync
with the primary copy of data but it was up to the client to make a
determination about where the mailbox was currently located. The other
drawback to SCR as opposed to CCR was that SCR required an administrator
to make manual changes to the systems in order to bring up a remote
copy of the mailbox database. DAG made an important improvement by
moving the logic for finding the active copy of the database from the
client to the client access servers. In this manner, clients that could
not previously redirect themselves based on information in Active Directory
can now successfully connect to their mailbox when the primary copy is
moved to another location. Like SCR, DAG doesn’t need to share the
identity of the server as the middle tier of this application
architecture is able to determine that automatically.
Backing Up a Database Availability Group
Exchange Server 2010 provides no native methods to backup mailbox
data in the traditional sense. Even for third party backups, the old
style of streaming backups is no longer supported. The only option is to
utilize a VSS based backup. However, consider the possibility that with
Database Availability Groups and an appropriate retention policy, it
might not be necessary to backup Exchange Server 2010 at all.
Consider, for example,
an environment with a written policy that “no email shall be retained
for more than 30 days in a backup.” For companies that don’t have
specific regulatory requirements for mail retention, this is actually a
fairly common situation. Now imagine that Exchange Server 2010 mailbox
databases are configured with a retention of 30 days. This is to say
that a user can use Outlook to “undelete” a message that has cleared the
Deleted Items folder for up to 30 days. This means that the only thing a
backup needs to protect against is a failure of the database or the
storage, as accidental deletions are covered for up to 30 days. By
definition, DAG is providing a remote backup that is an independent copy
of the mailbox database. This means that if the active database copy
were corrupted or if there was a hardware or storage failure of the
active copy, the next priority copy of the mailbox database would
automatically take over and there would be no loss of messages.
Similarly, because there are multiple replicas of the mailbox databases,
there would really never be a situation in which it was necessary to
restore a mailbox database. Not unlike a domain controller, an
administrator would simply build a new one and let it replicate with the
other copies.
This ability to
replicate rather than restore replicas offers an interesting
possibility. In older versions of Exchange Server, one could restore a
mailbox server to current by restoring an older database from tape and
replaying the log files, assuming the log files were still available on
the system. This is why it was always critical to store the log files
separately from the databases. In an Exchange Server 2010 DAG, there is
no need to restore from tape and replay logs, which raises the question,
why bother to maintain log files?
One could configure
their environment to have three or more DAG nodes and enable circular
logging for the Exchange Server databases. This would eliminate the need
to perform log truncations, which is one of the primary reasons that
backups are run in Exchange Server 2007 and older environments.
For longer term
backups, one could dismount the databases on an inactive DAG replica and
simply copy those files to another location. Now there would be a point
in time backup that could be stored long term. One could even use
something like Single Mailbox Recovery
tool from NetApp to mount the edb file directly and recover individual
messages without even having to put it back onto Exchange Server.
A similar option would be
to snapshot the storage if one were using a SAN to host the Exchange
Server 2010 data and that SAN supported snapshots.
