Microsoft Exchange Server 2010: Backup with Windows Server Backup
Using Windows Server Backup to create backup files for Exchange is a good approach, but will require some special configuration.
Excerpted from “Exchange 2010 - A Practical Approach,” published by Red Gate Books (2009).
Jaap Wesselius
The Windows Server Backup (WSB) function of Windows Server can be an effective way to create an Exchange backup, but it’s not without some special configuration. When backing up your Exchange data using WSB, you’ll need at least one disk to store the backups. This can be either a physical disk in the server or a disk on a storage device.
When starting WSB there will be no indication that it’s Exchange Server 2010-aware. When the Exchange databases are located on drive G:\ and drive H:\, for example, you must manually select these drives in WSB.
After selecting these disks, select another disk to store the actual backup. This can be any disk, except the ones being backed up or the system disk (that is, the C:\ drive). When the backup is running, you’ll notice that WSB checks the Exchange database for consistency.
When WSB has finished backing up the Exchange database, the header of the database is updated with relevant backup information. You can examine the status of the database using ESEUTIL /MH:
G:\mailbox database 0242942819>eseutil /mh "mailbox database 0242942819.edb" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Database: mailbox database 0242942819.edb Previous Full Backup: Log Gen: 4-5 (0x4-0x5) - OSSnapshot Mark: (0x6,8,16) Mark: 08/08/2009 11:39:06 Previous Incremental Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Operation completed successfully in 0.31 seconds. G:\mailbox database 0242942819> [Edited for readability]
WSB also logs all activities in the Event Log. When checking the Event Viewer you’ll see the Extensible Storage Engine (ESE) and MSExchangeIS events, such as:
Log Name: Application Source: ESE Date: 8-8-2009 11:39:05 Event ID: 2005 Task Category: ShadowCopy Level: Information Keywords: Classic User: N/A Computer: EXMBX12.labs.local Description: Information Store (2444) Shadow copy instance 1 starting. This will be a Full shadow copy. For more information, click https://www.microsoft.com/contentredirect.asp.
You’ll also see something like:
Log Name: Application Source: MSExchangeIS Date: 8-8-2009 11:39:05 Event ID: 9811 Task Category: Exchange VSS Writer Level: Information Keywords: Classic User: N/A Computer: EXMBX12.labs.local Description: Exchange VSS Writer (instance 1) has successfully prepared the database engine for a full or copy backup of database 'mailbox database 0242942819'.
When the backup has successfully finished, the log files will be purged. Which log files are purged will depend on how busy the server is during backup (if, for example, there are numerous new messages, mailboxes being moved and so on) and the checkpoint depth. Purging the log files is logged in the Event Log as well:
Log Name: Application Source: ESE Date: 8-8-2009 11:39:19 Event ID: 224 Task Category: ShadowCopy Level: Information Keywords: Classic User: N/A Computer: EXMBX12.labs.local Description: Information Store (2444) mailbox database 0242942819: Deleting log files G:\mailbox database 0242942819\E0000000001.log to G:\mailbox database 0242942819\E0000000003.log.
WSB is only capable of creating a full backup or a copy backup. It doesn’t support incremental or differential backups.
Database replication
WSB can also create backups of databases that are part of a database availability group (DAG). One limitation of WSB, however, is that it can only create a backup of an active copy of the database. If you create a backup of an active copy, the backup will succeed. When that active copy moves to another server and the local database becomes passive, the backup will fail.
The process of creating backups is identical to the previously described process, except for the truncated log files. Log files are only truncated if all log files are replicated and relayed to other database copies. Only then will the log files on the active copy be truncated. This can take some time, which is no reason for worry. It’s also logged in the Event Log:
Log Name: Application Source: MSExchangeIS Date: 8-8-2009 11:54:16 Event ID: 9827 Task Category: Exchange VSS Writer Level: Information Keywords: Classic User: N/A Computer: EXMBX01.labs.local Description: Exchange VSS Writer (instance 725e6ff5-7fd0-4c52-9bf1-f62fafc425ea:5) has successfully completed the full or incremental backup of replicated database 'Mailbox Database 1444276156'.
The log files will be truncated after you replay them.
High availability
For a completely highly available Exchange Server 2010 environment, you have to configure the Mailbox servers as such, but also the Hub Transport servers, Client Access servers and Edge Transport servers (if you’re using them). The high availability (HA) configurations for these other server roles are quite different from the Mailbox server role. They are, however, similar to their Exchange Server 2007 configurations.
Hub Transport servers
For transport redundancy, you’ll need at least two Hub Transport servers. When creating a Send Connector, you can define the source server that sends out the messages over this connector. For redundancy, you can add a second Hub Transport server as a source server:
- Log on to an Exchange Server and open the Exchange Management Console.
- Expand the Exchange On-Premises server and expand the Organization leaf. Click the Hub Transport leaf and select the Send Connectors tab.
- Right-click the Send Connector you need to change and select Properties.
- In the properties of the Send Connector, select the Source Server tab.
- Click the Add button to add a second Hub Transport server to the Send Connector.
- After selecting the second server, click OK twice.
The Hub Transport server will now have a redundant path, and will automatically load balance outbound messages over both source servers. It will use a round-robin mechanism for load balancing outbound SMTP traffic on both Hub Transport servers.
For inbound messaging, you need to manually implement a load-balancing solution. This can be an Interent Security and Acceleration (ISA) Server 2006 or any other hardware device capable of load balancing SMTP traffic. You can also use Windows Server 2008 Network Load Balancing (NLB), as this is an out-of-the-box Microsoft solution.
Using NLB, you can build a load-balancing solution running on Windows that will track all incoming connections and automatically load balance requests between the Hub Transport servers. This is a fully supported solution since Exchange Server 2007 SP1. The last option is to use DNS round-robin to load balance incoming traffic.
NLB is only supported for inbound SMTP connections, not for outbound SMTP connections. You can’t install it on any server that’s already hosting a DAG. A server hosting a DAG must have Windows failover clustering in operation, and NLB can’t coexist with Windows failover clustering.
Client Access servers
For redundancy on the Client Access server layer, you’ll need to implement at least two servers, which should be load balanced on the protocol layer. The load-balancing solution can either be a Microsoft ISA Server 2006 solution or a hardware-based load-balancing solution. As with the Hub Transport server, you can also use NLB for load balancing connections on the Client Access server (unless it’s hosting a DAG).
Edge Transport servers
When using an Edge Transport solution in the DMZ of your network, you’ll need at least two Edge Transport servers. Bear in mind that all Edge Transport servers have their own instance of the Active Directory Lightweight Directory Service (AD LDS, previously known as Active Directory Application Mode, or ADAM). Also, all Edge Transport servers have their own subscription to the Hub Transport servers in the company network.
When multiple Edge Transport servers are connected to the same site, they’re automatically added as source servers to the inbound Send Connector. Load balancing takes place across these Edge Transport servers in the same way as on the Hub Transport servers.
With the new DAG functionality in Exchange Server 2010, you can now create HA solutions on the Mailbox server level. This functionality replaces the Continuous Cluster Replication (CCR) and Standby Continuous Replication (SCR) in Exchange 2007. To be honest, the DAG is what CCR/SCR should have been. It’s flexible, powerful and less complex than the CCR/SCR solution. It’s truly the best of both worlds.
The HA solutions on the Hub Transport server role and Client Access server role are implemented with protocol load balancing. You can achieve this using a hardware load balancer or Windows NLB, or by using DNS round-robin. This process hasn’t changed much.
You should now be able to ensure your Exchange Server is always up and running. Of course, this is just a practical guide to get you started. There’s much more to learn to make your Exchange environment disaster-proof.
.jpg "Jaap Wesselius")
Jaap Wesselius is the founder of DM Consultants, a company with a strong focus on messaging and collaboration solutions. After working at Microsoft for eight years, Wesselius decided to commit more of his time to the Exchange community in the Netherlands, resulting in an Exchange Server MVP award in 2007. He’s also a regular contributor at the Dutch Unified Communications User Group and a regular author for Simple-Talk.
Learn more about “Exchange 2010 - A Practical Approach” at red-gate.com/our-company/about/book-store.