5. Online Move-Mailbox
The online Move-Mailbox feature is new in Exchange
Server 2010. In older versions of Exchange Server, the mailbox is taken
offline when it is being moved from one server to another server, to
prevent users from accessing any of their data, and queuing up any
incoming messages. There are situations when a huge (5GB) 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 and, as such, the end-user experience has been greatly improved.
This is what happens during an online Move-Mailbox, when a mailbox is moved (see Figure 9) from one server (EXBMX01) to another server in the same organization (EXMBX11), for example:
On
Mailbox Server EXMBX11, an empty copy of the user's mailbox is created,
just like a "legacy" move-mailbox operation. But instead of taking the
current mailbox offline (on EXMBX01), the original mailbox is kept
online. This is still the primary mailbox for the client, and new
messages still are delivered in this mailbox.
The
contents of the "old" mailbox are copied over to the mailbox on server
EXMBX11 and this mailbox is synchronized with the old mailbox.
As new items are delivered to the old mailbox, they are immediately copied over to the new mailbox.
When both mailboxes are in sync, the old mailbox is taken offline and the last messages are copied over to the new mailbox.
Active
Directory is updated with the location of the new mailbox, and the
mailbox is brought online again. The user may need to restart their
Outlook client, but the Client Access Server should automatically detect
that the mailbox has moved, and start using the new location. Either
way, the user can continue working in just a matter of seconds.
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.
6. Backup and restore
Exchange Server 2010 only runs on Windows Server 2008
and Windows Server 2008 R2. This means that the (free) NTBackup utility
in Windows Server 2003 cannot be used to backup Mailbox Databases on
Exchange Server 2010. In any case, NTBackup was only capable of creating
"streaming backups" of your Exchange data, not Volume Shadowcopy
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.
6.1 VSS or snapshot backups
With Exchange Server 2010, Microsoft has finally 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 point in time, which can be used to roll back the database in
case of a disaster. The Volume Shadow Copy Service, in Windows Server 2003 and later, provides an infrastructure to create these point-in-time images, which are called Shadow Copies.
There are two kinds of Shadow Copies:
Clone
(Full Copy or Split Mirror) – a complete mirror is maintained until an
application or administrator breaks the mirror. From this point on, the
original and the clone are fully independent of each other, and the copy
is effectively frozen in time.
Copy on Write
(Differential Copy) – a shadow copy is created as a differential rather
than a full copy of the original data. Using Copy on Write, a shadow
copy of the original data is made before it is overwritten. Effectively,
the backup consists of the data in the shadow copy combined with the
data on the original location, and both need to be available to
reconstruct the original data.
The Volume Shadow Copy Infrastructure consists of the following components:
Requestor –
this is the software that invokes the VSS and creates, breaks or
deletes the shadow copy. The Requestor is typically the backup
application.
Writer
– a software part that is provided by an application vendor. In our
case this is provided with the Microsoft Exchange Server. A writer is
responsible for providing a consistent point-in-time image by freezing
or quiescing the Exchange Server at the relevant moment. Please note
that an Exchange writer is provided for Exchange Server 2003 and higher,
right out of the box.
Provider
– a provider is the interface to the point-in-time image. This can
either be on a storage array (hardware provider) or in the Operating
System (software provider). Windows Server 2003 and above incorporate a
software Provider with VSS functionality out of the box.
The following steps occur when a VSS backup is performed:
The
Requestor (i.e. the backup application) sends a command to the Volume
Shadow Copy Service to create a shadow copy of the Storage Groups.
The VSS service sends a command to the Exchange writer to prepare for a snapshot backup.
The
VSS service sends a command to the appropriate storage provider to
create a shadow copy of the Exchange Storage Group. This storage
provider can be a hardware storage provider or the default Windows
storage provider.
The
Exchange writer temporarily stops or quiesces the Storage Group and
puts them in read-only mode. A log file roll-over is also performed to
make sure that all data will be in the backup set. This will hold a
couple of seconds for the snapshot to be created (in the next step). All
write I/Os will be queued.
The shadow copy is now created.
The VSS service releases the Exchange server to resume ordinary operations and all queued write I/Os are completed.
The
VSS service queries the Exchange writer to confirm that the write I/Os
were successfully held during the shadow copy creation. If the writes
were not successfully held it could mean a potentially inconsistent
shadow copy, so the shadow copy is deleted and the requestor is
notified. The requestor can retry the shadow copy process or fail the
operation.
If
successful, the requestor creates either a differential or a clone
snapshot, and then verifies the integrity of the backup set (the clone
copy). If the clone copy integrity is good, the requestor informs the
Exchange Server that the backup was successful and that the log files
can be purged. The backup is now complete.
NOTE
It is the
responsibility of the backup application to perform a consistency check
of the shadow copy. The Exchange writer does not perform this check.
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 still take hours
to complete depending on the size of the databases.
6.2 Backup with Windows Server Backup
Windows Server Backup is a feature in Windows 2008
(R2), and it can be installed using the Server Manager. Open the Server
Manager, select Features, and then select the Windows Server Backup in
the feature list to install it. When backing up your Exchange data using
Windows Server Backup, at least one disk is needed to store the
backups. This can be either a physical disk in the server or a disk on a
storage device.
When starting Windows Server Backup there's no
indication that it is Exchange Server 2010 aware; when the Exchange
databases are located on drive G:\ and drive H:\, these drives have to
be manually selected in Windows Server Backup. After selecting these
disks, another disk needs to be
selected to store the actual backup. This can be any disk, except the
ones that are being backed up or the system disk (i.e. the C:\ drive).
When the backup is running, you'll notice that Windows Server Backup
checks the Exchange database for consistency.
When Windows Server Backup has finished backing up
the Exchange database, the header of the database is updated with
relevant backup information. The status of the database can be examined
using ESEUTIL /MH:
[Edited for readability]
Windows Server Backup also logs all activities in the
Eventlog. When checking the Eventviewer you'll see the ESE and
MSExhangeIS events, like:
And
When the backup has successfully finished, the log
files will be purged as well. Which log files are purged will depend on
how busy the server is during backup (lots of new messages, moving
mailbox, etc.) and the checkpoint depth. Purging the log files is logged
in the Eventlog as well:
NOTE
Windows Server Backup
is only capable of creating a full backup or a copy backup. Incremental
or differential backups are not supported.
6.3 Windows Server Backup and database replication
Windows Server Backup can also create backups of
databases that are in a Database Administration Group (DAG), although a
limitation of WSB 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, but when the active copy moves to another server and the
local database becomes passive, the backup will now fail!
The process of creating backups is identical as in
earlier paragraphs, except for the truncation of 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 is
also logged in the Eventlog:
