You can create and manage copies of Exchange databases for archiving and disaster recovery purposes.
Excerpted from “Exchange 2010 - A Practical Approach,” published by Red Gate Books (2009).
A database copy is just what it sounds like: a copy of an active database. However, it’s often stored on another Exchange Server, in the same database availability group (DAG). When you initially configure Exchange, there’s a copy of the database file sent to the other server. When you’re finished, Exchange Server 2010 starts replicating the log files of this particular database over the network to the other server.
The relative location of the passive copy of the database is identical to the location of the active copy. For example, an initial database on an Exchange Server 2010 Mailbox Server may be located in the directory C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1444276156. If there’s a database copy enabled for this server, the same directory is created on the second server.
The process of copying a database to a second location is known as seeding. It’s a best practice to use separate disks for Exchange databases, both from a performance perspective as well as a disaster recovery perspective. After configuring Mailbox Database 1444276156 to use the separate disk G:\ for storing its information, you can configure the database copy:
Once the process is finished, log on to the target Exchange server. You’ll notice that on this server (on the G:\ disk in this example) there has been a Mailbox Database 1444276156 directory created where the copy of the database is stored. You’ll also see the log files replicated to this directory.
If there are a lot of databases used on an Exchange Server, using mount points is a valid alternative. In a mount point scenario, Server Manager mounts all data disks to a directory on the server—for example, F:\DB01, F:\DB02, F:\DB03 and so on.
In an Exchange Server 2007 Cluster Continuous Replication (CCR) environment, the active server also ships log files to the passive server. This in turn also loads the log files into its copy of the database. The passive server is truly passive, however. The service responsible for the database and the log files (store.exe) isn’t running. The only service that’s running is the replication service. During a failover, the passive node has to start all Exchange services. You need to have all databases mounted before that can happen.
In Exchange Server 2010, the store.exe service is already running and the databases are already mounted on all machines in a DAG. Therefore, database failover is much faster, resulting in a much shorter overall failover time.
For maintenance purposes, you can move an active database copy from one Exchange Mailbox Server to another with the following steps:
The online Move-Mailbox feature is new in Exchange Server 2010. In older versions of Exchange Server, the mailbox is taken offline when it’s moved from one server to another server. This prevents users from accessing any of their data and queuing up any incoming messages. There are situations when a huge (5GB and up) mailbox has to be kept offline for more than an hour while the move takes place. None of these make for a particularly usable system.
With the new online Move-Mailbox functionality—now called New-MoveRequest—the time a mailbox is offline has been reduced to only seconds. This greatly improves the UX.
This is what happens during a New-MoveRequest, when a mailbox is moved from one server (EXBMX01) to another server in the same organization (EXMBX11):
The online Move-Mailbox not only works between Exchange Server 2010 Mailbox Servers, but also when moving mailboxes from Exchange Server 2007 SP2 to Exchange Server 2010. Unfortunately, moving from Exchange Server 2010 to Exchange Server 2007 is still an offline move. Likewise, moving mailboxes from Exchange Server 2003 to Exchange Server 2010 is always an offline move.
Exchange Server 2010 only runs on Windows Server 2008 and Windows Server 2008 R2. This means you can’t use the (free) NTBackup utility in Windows Server 2003 to back up Mailbox Databases on Exchange Server 2010.
In any case, NTBackup will only create “streaming backups” of your Exchange data, not Volume Shadow Copy Service (VSS) backups of your Exchange database. Exchange Server 2010 contains a plug-in for the Windows Server Backup (WSB) to make it possible to create VSS backups of your Exchange Server 2010 databases.
With Exchange Server 2010, Microsoft has moved away from the traditional online streaming backup to VSS (or “snapshot”) backups. A snapshot is just an image of a database created at a particular moment. You can use this to roll back the database in the event of a disaster. VSS (in Windows Server 2003 and later) provides an infrastructure to create these point-in-time images called shadow copies. There are two kinds of shadow copies:
The VSS infrastructure consists of the following components:
The following steps occur when you perform a VSS backup:
Steps 1 through 7 usually take about 10 seconds, as this is the time needed to create the actual snapshot. This is not the time to create a backup, though. A backup application still has to create the backup on another disk or to tape, which can take hours to complete, depending on the size of the databases.
The backup is now complete. The backup application has the responsibility to perform a consistency check of the shadow copy. The Exchange writer doesn’t perform this check. It’s important to perform this check to ensure a clean and complete copy.
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.