Download Exchange DAG backup and design best practices

Exchange DAG
backup and design
best practices
Brien M. Posey
Modern Data Protection
Built for Virtualization
Exchange DAG backup and design best practices
Database Availability Groups (DAGs) are the primary fault-tolerant mechanism
used for protecting mailbox databases in Exchange Server 2010 and 2013.
DAGs allow administrators to create up to sixteen separate copies of mailbox
databases. DAGs allow for so much redundancy, in fact, that some people
(both inside and outside of Microsoft) have expressed the idea that DAGs
render Exchange Server backups obsolete. This article examines how backups
work in a DAG environment, and whether or not you should be backing up
your DAG members.
The Exchange Server backup process
Before I delve into a discussion of data protection within a DAG, I need to take
a moment and discuss the way that backups normally work in an Exchange
Server environment independent of DAGs.
When a backup application performs a backup of an Exchange Server,
the backup application acts as something that Microsoft refers to as a Volume
Shadow Copy Service (VSS) requester. The VSS requester’s job is to coordinate
the backup process with a series of VSS writers. Typically there will be several
different VSS writers present on an Exchange Server and each writer is
responsible for making sure that a specific type of data is backed up properly.
You can see a list of all of the VSS writers that are present on your Exchange
Server by entering the VSSAdmin List Writers command. For the purpose of this
discussion, I will focus on the Exchange VSS writer.
With that said, the backup software initiates a backup job by having the VSS
requester contact the Exchange Server and ask for a list of the VSS writers that are
present on the server. The Exchange Server returns a list of VSS writers in response.
At this point, the VSS requester contacts each VSS writer individually. In the case
of the Exchange VSS writer, the requester asks for the writer’s status and for
information about the Exchange Server resources that are present on the server
and where those resources reside. Specifically the Exchange VSS writer reports
on the names and locations of databases and their corresponding transaction
logs, as well as some other related metadata.
The next thing that has to happen is that the Exchange VSS writer freezes
the Exchange databases and the corresponding transaction logs. For all
practical purposes, this freezing process can be thought of as temporarily
flagging the databases and the transaction log folders as read only.
2
Exchange DAG backup and design best practices
Even though the Exchange databases and the corresponding transaction logs
are “frozen” the Exchange Server is able to continue to function throughout
the backup process. The reason for this is that even though Exchange is not
able to write to a frozen database or its transaction logs, it is able to store
transactions in memory.
Normally the backup process only requires a database to be frozen for about
sixty seconds (or less). During this time the VSS writer creates a VSS snapshot.
The snapshot operation’s anatomy can vary depending on how the server is
set up. In most cases the server creates a copy-on-write snapshot, although in
some special circumstances a clone snapshot may be created instead.
Windows designates a portion of each disk as shadow storage. The VSS writer
stores the snapshot in the shadow storage area. Generally speaking, each
disk contains its own shadow storage, so the database volume will contain
the database and the database snapshot.
It is extremely important to understand that the VSS snapshot is not the same
thing as a backup. For one thing, the snapshot exists on the same volume
as the resource that it is protecting, so if you lose the volume, you lose
the protected resource (such as an Exchange mailbox database) and the
corresponding snapshot.
The other reason why a snapshot is not the same thing as a backup is that
a copy-on-write snapshot is not a full copy of your Exchange database. Mailbox
database snapshots are designed to be created in one minute or less. In
many cases, making a second copy of a multi-terabyte database on the same
volume where it resides now would take much longer (especially on lower-end
hardware). Never mind the impact that storing multiple database copies would
have on your storage consumption.
The point is that a snapshot is not a full database copy. Instead, a snapshot is
designed to store copies of individual blocks of data.
After the snapshot is created, the database is thawed, which means that it
(and its transaction logs) once again become read/write. The problem is that
at this point the database has not been backed up yet. If the backup software
were to simply make a copy of the database in its current state, the database
would most likely be modified before the backup could be completed, thereby
resulting in a corrupt database copy.
This is where the snapshot comes into play. Any time that a write operation
needs to be performed against the database, Windows makes a copy of
the block before it is modified. This copy resides in shadow storage. That way,
the database can be modified, but there is still a copy of any modified blocks as
they existed prior to the modification.
3
Exchange DAG backup and design best practices
Transaction log processing
It’s impossible to talk about Exchange Server backups without discussing
transaction logs. The transaction log discussion will become even more
important later on when I begin discussing DAGs.
Exchange does not write transactions directly to a mailbox database. Instead,
the data is written to a transaction log. As such, the mailbox database almost
never contains data that is completely up-to-date.
The reason why Exchange Server writes data to log files instead of writing
the data directly to a mailbox database has to do with recoverability. To show
you why this is the case, imagine for a moment that transaction logs do
not exist and that all mailbox transactions are written directly to a mailbox
database. Now suppose that you back up the mailbox database and your
Exchange Server crashes two hours later. If you had to restore your most recent
backup, you would lose all of the data that had accumulated since the time
that the backup was created. Losing two hours’ worth of data might not initially
seem like a major problem, but in most organizations email is one of the most
mission critical applications, and data loss of any kind is problematic.
Simply put, transaction logs are designed to protect the data that has
accumulated since your last backup. However, they can only protect you if they
are stored on a separate disk (not just a separate volume) from the mailbox
database. If the volume containing the database were to fail, you could restore
your backup which would bring the database back to the state at which it
existed at the time that the backup was created. The transaction logs are then
used to retrieve any data that has accumulated between the time of the backup
and the time of the crash.
Obviously, the transactional data does not reside in the transaction logs forever.
It has to be written to the mailbox database at some point. This is actually
done as a part of the backup process. The log file contents are committed to
thedatabase. There is also a checkpoint file that keeps track of which log files
have and have not been committed.
When the backup process completes, there is some cleanup work that occurs,
which takes the database out of a “backup state.” This means purging any
snapshot data that is no longer needed and truncating transaction logs that
have been committed to the database.
4
Exchange DAG backup and design best practices
What about Database Availability
Groups?
The backup process that has been described so far is used both in standalone
Exchange deployments and in DAGs. However, DAGs complicate things a little
bit because multiple mailbox servers and multiple database copies are involved
in the process.
A DAG is a special type of failover cluster that provides fault tolerance for
Exchange mailbox databases. DAGs are able to make mailbox databases fault
tolerant by creating and maintaining multiple mailbox database copies.
In a DAG environment, the primary copy of a mailbox database is said to be
theactive copy, while any secondary copies are considered to be passive copies.
When it comes to DAG architecture, it is important to remember that there
is not necessarily a one-to-one ratio of DAG members to mailbox database
copies. For example, if you have a DAG that is made up of five mailbox
servers (a five-member DAG), it does not mean that you must have five copies
of each mailbox database. Most organizations that use DAGs try to strike
a balance between redundancy and storage and other hardware costs. Hence,
an organization with five DAG members might create three copies of one
database, two copies of a second database, and five copies of a third database.
You are free to mix and match levels of database redundancy within your DAG.
Do you need backups for Database
Availability Groups?
There is a notion within some segments of the IT community that if you can
create a DAG that provides a sufficient number of database copies, there is no
need to back up Exchange Server. After all, a backup is really nothing more than
a copy of your data. As such, some believe that an online database copy within
your DAG will work just as well as a backup.
While there is no denying the fact that there are enterprise-class organizations
that choose not to perform traditional backups of DAG members, I personally
believe that this approach (which is known as zero backups) is shortsighted.
One of the reasons for this is that restoring a backup allows you to revert
an Exchange database to an earlier point in time, while DAGs are primarily
oriented toward providing redundancy for databases in their current state.
5
Exchange DAG backup and design best practices
At first, the idea of providing redundancy rather than having the ability
to revert a database to an earlier point in time seems completely logical.
If Exchange Server truly is a mission-critical application and data loss is
unacceptable, rolling back a database to an earlier state would not fit into the
organization’s goals because it would result in data loss.
The problem with this philosophy is that redundancy alone only protects
against some types of problems, but not others. For instance, having
redundant database copies would protect you against a node failure or against
a server volume failure. However, this approach does not offer protection
against malware.
Suppose that a primary database copy became infested with a virus.
The malware infestation would be replicated to the other database copies,
thereby infecting all of your database copies.
In all fairness, Microsoft does give you a way to protect yourself against
the replication of unwanted data. The mechanism that allows a DAG to be
rolled back to an earlier point in time is called a lagged database copy.
In order to understand how a lagged database copy works, you have to
understand how normal DAG replication works. Rather than trying to keep
mailbox databases in perfect synchronization, DAG replication works by using
log shipping. When a transaction log file is closed out, the log is immediately
replicated to the other database copies.
Normally the passive database copies play back the log files and commit
their contents to the passive database copies. A lagged copy does not
immediately replay transaction logs as they are received. Instead, Exchange
waits for a predetermined period of time to play back the transaction logs for
lagged copies. This means that a lagged database copy is essentially a copy of
a database as it existed at an earlier point in time.
As you can see, lagged database copies can provide your DAG with rollback
capabilities. However, activating a lagged database copy is not a process to
be taken lightly. It can be extremely difficult to determine which transaction
logs should and should not be preserved. Furthermore, the technique used to
activate a lagged database copy is very tedious.
6
Exchange DAG backup and design best practices
With proper planning it is theoretically possible to provide real-time
and lagged protection to mailbox database copies using only native tools.
However, there are a number of things that must be considered prior to using
this approach. Some of the more important considerations are:
• If a database rollback is required then you must discover the problem, make
the decision to roll back the database, and complete the rollback process
within the time allowed by your lagged database copy.
• Unless you have multiple lagged copies of a single mailbox database, you
usually only have one chance to get the rollback right.
• Going without a traditional backup greatly reduces the number of recovery
options that are available to you. Do you really want to have to explain to
your boss that you can’t return Exchange to the desired state because you
have abandoned the process of backing up your Exchange Server?
• Traditional backups give you the option of storing offline copies of your data
in a secure location. Conversely, DAG replication stores passive database
copies on spinning disks.
Best practices for Database
Availability Group backups
As mentioned at the beginning of this whitepaper, DAGs are the primary mechanism
for protecting Exchange 2010 and Exchange 2013 mailbox databases. As such,
I highly recommend using DAGs to protect your data, but do not recommend using
DAGs as a substitute for regular Exchange Server backups. With that in mind, there
are several recommended best practices for DAGs that you should adhere to.
Windows Server Backup
First, don’t use Windows Server Backup to back up DAG members. Windows
Server Backup is perfectly capable of backing up DAG environments, but has
some major limitations. The most significant of these limitations is the fact
that Windows Server Backup can only back up active database copies. Most
of the third-party backup solutions can back up passive database copies. The
reason it is better to back up passive database copies is because the backup
process creates disk I/O. You really don’t want to generate additional disk I/O
on a volume containing an active database copy if you can avoid doing so.
7
Exchange DAG backup and design best practices
DAG architecture
Another recommendation is to be careful about creating a spanned DAG. It
is possible to build a DAG that spans multiple datacenters so that there is
always a database copy kept safely off site. However, if you are going to create
a spanned DAG then you must also span the Active Directory domain across
datacenters, because Microsoft requires all DAG members to exist within
a common domain.
While I am on the subject of spanned DAGs, I also want to mention that
spanned DAGs are very sensitive to latency. The WAN connection must support
a round-trip latency of 500 milliseconds or less.
You must also construct a spanned DAG in a way that will prevent a WAN
link failure from losing quorum, which would cause the DAG to fail. Doing
so means constructing the DAG in a way that guarantees that the majority
of the nodes (at least half + 1) are accessible at any given time. The most
reliable way of doing this is to place half of the DAG members at each of two
datacenters and then place a “tie breaker” DAG member of witness server at
an independent third location.
Database types
As a best practice, I recommend that any organization that has public folder
data upgrade to Exchange Server 2013. DAGs only support mailbox databases,
not public folder databases. Exchange Server 2013 allows public folder data
to be moved into a mailbox database, thereby giving administrators the ability
to offer DAG level protection for public folder data. This is simply not possible
in Exchange Server 2010.
8
Exchange DAG backup and design best practices
Log truncation
One last best practice is to base your log truncation method on your mailbox
server deployment type. As previously explained, under normal circumstances
log files are committed to the database as a part of the backup process. Once
everything has been backed up, Exchange truncates (purges) the log files that
are no longer needed.
One of the big questions that often comes up during the DAG creation process
is how log truncation should be handled since the log files must be replicated
to other DAG members.
Microsoft recommends that if you have non-replicated mailbox databases use
the log file truncation method that was previously discussed (http://technet.
microsoft.com/en-us/library/ee832792.aspx). Microsoft also recommends that
these servers be provisioned for three days of log generation capacity.
In the case of replicated databases, however, Microsoft recommends using
a log truncation method called circular logging. Circular logging uses and
reuses a finite number of log files as opposed to creating (and later truncating)
a continuous stream of log files. Lagged copies should be provisioned to
accommodate log files extending for three days beyond the lag period.
Conclusion
Although there is a notion among some IT professionals that DAGs make
traditional backups obsolete, backups generally provide a greater degree of
flexibility than DAGs can provide on their own. Even so, the only way to truly
protect your data is to make sure to adhere to the various recommended best
practices for DAGs when designing the DAG architecture and when planning
your backup solution.
9
Exchange DAG backup and design best practices
About the Author
Brien Posey is a freelance technical writer who has received
Microsoft's MVP award nine times for his work with Exchange
Server, Windows Server, IIS, and File Systems Storage.
Brien has written or contributed to about three dozen books,
and has written well over 4,000 technical articles and white
papers for a variety of printed publications and Web sites.
In addition to his writing, Brien routinely speaks at
IT conferences and is involved in a wide variety of other
technology related projects.
About Veeam Software
Veeam® is Modern Data Protection™. We believe today’s IT requirements
have changed and that “3C” legacy backup problems—high costs, increased
complexity and missing capabilities—are no longer acceptable for any
organization. Veeam provides powerful, easy-to-use and affordable solutions
that are Built for Virtualization™ and the cloud—a perfect fit for the modern
datacenter.
Veeam Backup & Replication™ is VMware backup, Hyper-V backup, recovery
and replication. This #1 VM Backup™ solution helps organizations meet RPOs
and RTOs, save time, eliminate risks and dramatically reduce capital and
operational costs. Veeam Backup Management Suite™ combines Veeam Backup
& Replication and Veeam ONE™ in a single integrated solution to protect
virtualization investments, increase administrator productivity and help mitigate
daily management risks. Veeam Management Pack™ (MP) extends enterprise
monitoring to VMware through Microsoft System Center. Veeam also provides
free tools for the virtualization community.
Learn more by visiting http://www.veeam.com.
10
Exchange DAG backup and design best practices
Modern Data Protection
Built for Virtualization
Powerful
Easy-to-Use
Veeam Backup & Replication
#1 VM Backup for VMware and Hyper-V
Virtualization changes everything – especially backup. If you’ve virtualized
on VMware or Hyper-V, now is the time to move up to the data protection
solution Built for Virtualization: Veeam Backup & Replication.
Unlike traditional backup that suffers from the “3C” problem (missing capabilities,
complexity and cost), Veeam is:
 Powerful: Dramatically improve your RPOs and RTOs
 Easy-to-Use: Save time and eliminate risk
 Affordable: Reduce TCO and increase ROI
Join the 73,000 organizations who have already modernized their data protection
with Veeam. Download Veeam Backup & Replication today!
GOLD AWARD
NEW
TECHNOLOGY
To learn more, visit http://www.veeam.com/backup
11