Exchange DAG backup and design best practices

Transcription

1 Exchange DAG backup and design best practices Brien M. Posey Modern Data Protection Built for Virtualization

2 Database Availability Groups (DAGs) are the primary fault-tolerant mechanism used for protecting mailbox databases in Exchange Server 2010 and 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

3 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

4 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 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

5 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

6 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

7 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

8 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 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

9 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 ( microsoft.com/en-us/library/ee 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

10 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 10

11 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 11