Beruflich Dokumente
Kultur Dokumente
TECHNICAL
John Phillips and Adrian Simays, Network Appliance Inc. | 8/2003 | TR 3233
Best Practices
1
TECHNICAL REPORT
Table of Contents
1 Introduction 3
7 Snapshot 15
10 Management Tools 26
11 Summary 29
13 Additional Resources 31
2
TECHNICAL REPORT
1) Introduction
This paper is intended to be a best practice guide and is for experienced Microsoft Exchange
administrators who have read the Network Appliance™ SnapDrive™ and SnapManager for Exchange
installation and administration guides. Readers of this best practice guide should have a solid
understanding of the Exchange storage architecture and Exchange administration, as well as Exchange
backup and restore concepts. The recommendations found in this document are best practices to
assist with the design and configuration of SnapManager for Exchange in Windows® 2000 and
Windows 2003 environments with Microsoft Exchange 2000 and Microsoft Exchange 2003.
Note: Both the SnapDrive and SnapManager for Exchange installation and administration guides can
be found at http://now.netapp.com (username and password required).
In order to design and implement highly available Exchange architectures, system managers must look
well beyond the availability of their server hardware. Exchange server scalability is often limited by how
long it takes to back up and restore data rather than by server performance.
Exchange databases can grow rapidly in size while storing e-mail, rich media, calendaring, and contact
and workgroup information. As the databases grow larger, it becomes increasingly difficult to complete
time-consuming tape backup operations in a reasonable amount of time. In the case of an outage it can
take days to restore service, assuming all of the backup tapes are available and error-free.
If a virus or software error renders a particular database inaccessible, all of the users whose mailboxes
exist within that database cannot access their data. The range of outages can be anywhere from a few
hours to several days or even a week or more. To improve data availability, administrators must strive
to balance server scalability and manageability by imposing mailbox limits and by limiting the number of
users per server or storage group.
Benefits at a glance:
Quickly back up and restore Exchange storage groups and databases using Network Appliance
Snapshot™ technology
The Network Appliance SnapDrive Microsoft Management Console (MMC) application provides
an easy-to-use graphical interface to simplify the management of NetApp disk, storage, and
Snapshot resources
3
TECHNICAL REPORT
Full integration with the Microsoft Volume Shadow copy Services (VSS) snapshot API
architecture when running Exchange 2003 on Windows Server 2003
Exchange data stored in Snapshot copies can be automatically mirrored to one or more
locations for archival or disaster recovery purposes
Exchange servers are able to serve more data and are easier to scale and manage
Flexible pools of storage can provide storage resources for multiple Exchange servers, and
capacity can be added on-the-fly without downtime as storage needs grow
The ability to quickly back up and restore online Exchange data in Snapshot copies is the primary
purpose of SnapManager for Microsoft Exchange. SME dramatically reduces the time it takes to back
up and recover Exchange data from online Snapshot files.
First, LUNs (disks) must be provisioned by the filer for use by the Exchange server(s). The process in
which LUNs are created and mounted by the Exchange server is summarized below:
2. LUN objects, which are created by using SnapDrive, are created on LUN-dedicated filer
volumes*
3. LUNs are mounted by the Exchange server and appear as “disks” with drive letters, etc.
*If file access (network shares) is required for home directories, etc., a separate volume should be
created for that purpose. To ensure optimum LUN performance, volumes created for LUNs should not
be used for other purposes.
The following formula can help you calculate your Exchange database size:
4
TECHNICAL REPORT
DB size = ((number of mailboxes * mailbox quota) / single instance sharing ratio) + deleted item cache
Where:
The single instance ratio can be found through a performance monitor counter under
MSExchangeIS Private. In the following example it is calculated to be 1.5.
Applying this result for future growth, assuming the Exchange environment will grow by 10% annually
over the course of three years (for illustration purposes only), add an additional 24GB ((80GB * .10) *
3).
The following formula works best for calculating virtual disk size required for a transaction log drive:
Virtual disk size = ((number of transaction logs generated per day * 5MB) * (number of Snapshot copies
to keep online + 1 for the active file system))
Where:
Each transaction log is 5MB (after a log file is filled, a new 5MB log file is created)
If a server generates 200 transaction logs in one day, then there is about 1GB of transaction logs at the
end of the day (200 * 5MB = 1GB). If the plan is to keep five days of SnapManager backups online at
the same time, then:
Note: If storing transaction logs from multiple storage groups on the same virtual disk, then apply this
formula to each set of transaction log files and combine the total of each transaction log set to estimate
a virtual disk size.
Snapshot Management
When sizing virtual disks for Microsoft Exchange, consider the number of Snapshot copies that will be
created and the length of time they will be kept. Disk space consumed by a Snapshot backup consists
only of the blocks that have changed since the last one was created.
For example, a 100GB store has a Snapshot copy created at midnight. If between midnight and noon
the following day, 500MB of data was added to, changed in, or deleted from the information store data
5
TECHNICAL REPORT
However, if that same 100GB store Snapshot copy was kept for 20 days and experienced the same
rate of data change during that period, the Snapshot copy would now consume 10GB (500MB * 20
days). Properly managing Snapshot requires balancing the number of copies and the length of time
they are kept.
Space Reservation
As part of the space reservation feature, WAFL® reserves blocks equal to two times the specified size
of the LUN being created. If a volume of 80GB is being created with a planned growth rate of an
additional 24GB, enough spindles to accommodate 208GB ((80 + 24) * 2) will be required. Space
reservation is designed to guarantee writes for virtual disks. More information on space reservations
can be found later in this document.
Migration Impact
Migrations are another factor that can influence available disk space. When migrating from an existing
mail system to Microsoft Exchange, single-instance store features are unavailable. Single-instance
store provides pointers to a single mail message, so one 100kB e-mail sent to 50 people in the mail
system will require 100kB of space (Exchange 2000 supports single-instance store per storage group).
Since single-instance stores cannot be retained during a migration, 50 instances of the 100kB e-mail
will require 5MB of space. Once the migration is complete, new e-mails received in Exchange will be
stored using the single-instance store. (Even during Microsoft Exchange 5.5 to Microsoft Exchange
2000 upgrades you may require up to 30% more disks during the migration process. Be prepared to
design the volumes with enough free space to accommodate the migration, even if this space is
unused once the migration is complete.)
* This number represents a single storage group containing 1,000 users with 100MB per mailbox.
6
TECHNICAL REPORT
Following the examples provided in this section, one could estimate the volume size for the transaction
log volume to be:
Remember, there may be times when the number of mailboxes or the size of the public folders
sporadically grows on an Exchange server and thus requires additional free disk space. Having extra
free disk space on hand avoids emergency administrator intervention.
Unlike traditional storage systems, NetApp filers allow disks to be added on-the-fly on an as-needed
basis as storage needs grow.
The databases within a given storage group must reside on a dedicated LUN. All databases within a
storage group are backed up and restored together. Restoring an individual database within a storage
group is not possible unless that database (priv.edb, for example) resides on its own dedicated LUN.
However, the transaction logs from different storage groups can share a LUN.
7
TECHNICAL REPORT
SMTP Mailroot directories on a dedicated volume. When messages arrive at the Exchange 2003 server
through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are
stored locally on the Exchange server. The SMTP Mailroot directories include:
msExchSmtpBadMailDirectory
msExchSmtpPickupDirectory
msExchSmtpQueueDirectory
Moving these directories requires editing Active Directory; administrators must use caution when
performing this action. More information can be found in Microsoft's Knowledge Base Article 318230.
For more information on MSCS clusters and Exchange, please see the Additional Resources section at
the end of this paper.
Another consideration when storing multiple LUNs on the same filer volume is performance. Avoid
placing heavily used storage groups on the same volume. Filer volumes used for Exchange should
never be shared with non-Exchange data.
Remember, Exchange databases and Exchange log files should never be stored on the same volume.
Filer Requirements
Data ONTAP 6.5 or above and SnapDrive 3.0; for current Data ONTAP requirements please
visit http://now.netapp.com
FCP, iSCSI, SnapRestore®, and SnapMirror® (if SnapMirror is used) licenses must be enabled
8
TECHNICAL REPORT
A qualified Gigabit or Fibre Channel host bus adapter (HBA) target card for use with iSCSI or
FCP
SnapDrive provides a layer of abstraction and a consistent, transparent interface between Network
Appliance filers and Windows applications. The Fibre Channel protocol (FCP) and iSCSI resources that
are managed by SnapDrive appear to the Windows host server and its applications as locally attached
disks.
In addition to providing a management interface and presenting NetApp LUNs to the Windows
operating system as basic disks, SnapDrive is capable of managing all of the functions related to
Snapshot copies.
Prior to launching the installation of SnapDrive, use the following checklist to help eliminate the
potential for errors or delays during or after the installation.
Make sure all of the necessary software and printed or electronic documentation (found on
http://now.netapp.com) are organized and nearby before beginning.
o Verify that all related systems, including filers, Exchange servers, and clients, are
configured to use an appropriately configured DNS server (for more information, see
TR 3124 at www.netapp.com/tech_library/3124.html).
o Enable, configure, and test RSH access on the filer(s) for administrative access (for
more information, see the Data ONTAP product documentation).
Configure the filer(s) to join the Windows 2000 or Windows 2003 Active Directory domain by
using the FilerView® administration tool or by running filer> cifs setup on the console (for more
information, see Chapter 3 of the Data ONTAP 6.5 File Access Management Guide).
9
TECHNICAL REPORT
Make sure the filers' date and time are synchronized with the Active Directory domain
controllers. This is necessary for Kerberos authentication. A time difference greater than five
minutes will result in failed authentication attempts.
Verify that all of the service packs and hot fixes are applied to the Microsoft Windows and
Microsoft Exchange servers.
SnapDrive Installation Tips
Prior to installing the SnapDrive application, the iSCSI or Fibre Channel HBA drivers must be installed.
The SnapDrive installation wizard provides an option to install the drivers before proceeding with the
installation.
Note:
Do not proceed with the SnapDrive 3.x installation until the iSCSI or HBA drivers are installed
and the host rebooted.
10
TECHNICAL REPORT
Once the device driver is installed, select the same account used by the Microsoft Exchange services
when selecting the service account for the SnapDrive and SnapManager for Microsoft Exchange
services.
When creating or configuring the properties for the domain service account, select the “Password never
expires” checkbox. Doing so protects the account and service from failing due to user password
policies.
Reminder: It's important to make certain the service account has the following permissions:
Read and write or full control access to the locations on the filer in which LUNs will be created
(likely if it's already a member of the administrator's group).
RSH access to the filer(s). For more information on configuring RSH, see the Data ONTAP
Administration Guide.
11
TECHNICAL REPORT
When using SnapManager for Microsoft Exchange in conjunction with Microsoft Exchange 2003 and
Windows Server 2003; the NetApp VSS Hardware Provider must be installed. Customers may
download the NetApp VSS Hardware Provider software from http://now.netapp.com. For more specific
information and system requirements on installing SnapManager for Microsoft Exchange, see Chapter
2 of the SnapManager for Microsoft Exchange Installation and Administration Guide.
SnapManager for Microsoft Exchange is integrated with the VSS architecture in Windows Server 2003
and Exchange Server 2003. The following chart describes where SnapManager for Exchange and
NetApp storage fit into the VSS framework.
VSS Requestor
NetApp SnapManager for Microsoft Exchange
VSS Writer
Exchange Server 2003
The process of creating a LUN is virtually the same, and there is no distinction at the host application
level. LUNs are virtual disks on the filer that are accessed over either TCP/IP (for iSCSI) or Fibre
Channel (for FCP) disk access protocols.
When specifying a UNC path to the volume or qtree to create a LUN, use IP addresses instead
of host names. This is particularly important with iSCSI, as host-to-IP name resolution issues
can interfere with the locating and mounting of iSCSI LUNs during the boot process.
Always use SnapDrive to create LUNs for use with Windows to avoid the complexities inherent
in Fibre Channel.
Calculate disk space requirements to allow for data growth, Snapshot copies, and space
reservations.
12
TECHNICAL REPORT
Leave automatic Snapshot scheduling off as configured by SnapDrive. To turn off automatic
Snapshot activities, use FilerView or the following example command:
Verify that all of the hardware and software meets the supported system requirements. The
latest hardware and software requirements for filer platforms, host platforms, Fibre Channel
switches, and third-party software are available on the NOW™ Web site. Log onto the NOW
Web site at http://now.netapp.com and view the SAN support matrix for the latest information
and updates.
For more information on configuring Fibre Channel between Windows hosts and filers, please
see the Host Bus Adapter Installation and Setup Guide for Fibre Channel Protocol on Windows.
13
TECHNICAL REPORT
Esefile
Microsoft's esefile utility verifies the page-level integrity of the Exchange databases and is required by
SME. Esefile can be found on the Microsoft Exchange server/service pack CD located under
Support\Utils\i386 (since the esefile utility is updated with service pack releases, you must manually
copy this utility from the latest Exchange service pack).
Upon first use of SME, the user is prompted to specify the location of the esefile.exe utility. While it is
possible to cancel this request, it will appear during every use of the management console until
configured. If page file verification is not run during the backup process, it will be required prior to a
restore.
When configuring a cluster environment, it is critical to install SME on both nodes of the cluster. In the
event the first node in the cluster becomes unavailable, the SnapManager functions can immediately
be performed on the second node without waiting.
Installing SnapManager for Exchange on the cluster nodes is the last step when configuring a clustered
Exchange environment.
1. On the first node of the cluster, install SME and use the configuration wizard to move the
Exchange data paths to the LUN resource locations.
2. Create a Snapshot backup of the Exchange environment after the installation and configuration
are complete on the first node.
3. After a successful backup, fail the cluster to the second node in the cluster and ensure the
Exchange services work as expected.
4. Install SME on the second node of the cluster and run the configuration wizard to update the
database locations on the server.
5. Create another Snapshot copy of the data to ensure backups work from both nodes of the
cluster.
The full Exchange migration guide and upgrade steps can be found at http://now.netapp.com.
An important step prior to migrating databases to Exchange 2000 or Exchange 2003 is to run the
esefile (eseutil for Exchange 2003) utility on the Exchange 5.5 database. Esefile will check the
consistency of the data to ensure there are no problems with the data prior to migration. If the esefile
14
TECHNICAL REPORT
utility is not run against the database and an Exchange upgrade fails, the entire environment must be
rolled back to an Exchange 5.5 environment before recovering to a recent Snapshot backup.
7) Snapshot
It is beyond the scope of this paper to explore Snapshot in great detail. However, it is necessary to
understand the fundamentals of the unique Network Appliance Snapshot functionality and how it
relates to Microsoft Exchange.
Network Appliance Snapshot backups occur in a matter of seconds, and each consumes only the
amount of disk space that has changed since the last Snapshot copy was created. Thus they consume
minimal disk space while providing up to 255 online point-in-time images using Data ONTAP 6.4. The
amount of disk space consumed by an individual Snapshot copy is determined by two factors:
The rate data changes within the file system (in MB/sec or MB/hour, for example)
For more information on Snapshot technology and Snapshot internals, see TR 3043, SnapMirror and
SnapRestore: Advances in Snapshot Technology (www.netapp.com/tech_library/3043.html).
15
TECHNICAL REPORT
write data is required. This is because Microsoft Exchange must be able to update the database
headers in order to mount them.
LUNs in Snapshot can be mounted for write access by using the Connect Disk function within
SnapDrive to connect to a LUN in a Snapshot copy.
Special virtual disk files with an .rws extension are created when connecting to a LUN to facilitate this
purpose. Instead of taking the time to copy the Snapshot data into the active file system, the .rws file is
linked to the original Snapshot data. Therefore read requests are read from the Snapshot data, and
writes are written to the .rws file. When the read/write Snapshot copy is no longer required and
SnapDrive is used to disconnect from the (rws) virtual disk, the .rws file is deleted along with any writes
that occurred to the .rws file. Therefore the source Snapshot copy is not modified.
16
TECHNICAL REPORT
Note: Though technically possible, it is not recommended to create duplicates of read/write Snapshot
copies (.rws files) unless absolutely necessary.
Space Reservation
Space reservation is designed to ensure that protected files (or files that have space reservation turned
on) always have the free space they expect and so that a Snapshot copy of the LUN can complete
even if 100% of its blocks have changed.
Data ONTAP 6.3x only allowed space reservation to be turned on or off at the volume level. Data
ONTAP 6.4 provides for space reservation at the qtree and file levels. Any file may be designated as
protected, but it is turned on by default for LUNs. The rest of this section will discuss space reservation
as it exists in Data ONTAP.
When creating a virtual disk, the filer verifies there is enough available disk space to accommodate the
specified size. By default, WAFL reserves blocks equal to two times the specified size of the LUN so
that all future writes can complete. If space reservation was not enabled, it would be possible to
oversubscribe the available storage. If this occurred, Exchange could unexpectedly run out of disk
space while trying to complete writes to one of its database files.
On each filer volume, reserved space equal to the amount of protected space for all virtual disks (and
any protected files) is set aside. The amount of reserved space is dynamic and can vary if protected
files are added, deleted, etc. If the available disk space runs low, writes to unreserved files and the
creation of Snapshot backups are restricted in favor of completing writes to protected files.
Databases in particular do not react well to surprises stemming from failed file system writes. Microsoft
Exchange somewhat anticipates the possibility of running out of space by its use of reserve logs, but
reserve log files are only designed to capture a very small amount of data required to shut down a
storage group in a consistent state.
Note: SnapDrive requires that all LUNs have space reservation enabled. Disabling space reservation
for a LUN is not supported with SnapDrive.
17
TECHNICAL REPORT
administrators into scheduling SnapManager backups in frequencies as often as hourly. While this
strategy would provide quick recovery times due to the minimal amount of transaction replay during a
restore, there is a catch. Keep in mind that only esefile-verified SnapManager backups can be archived
to tape. Remember, esefile verification will impact the Exchange server's CPU and should be run from
a server other than the production Exchange server.
The best strategy for SnapManager and tape archive schedules is to consider the tape backup strategy
required to meet SLAs, the desired total number of SnapManager backups per day, Exchange client
activity schedules, and the total time required to complete esefile verification. Then devise a schedule
that allows for esefile verification to complete and does not encroach on the time necessary to
complete a tape archive.
For example:
With this data, esefile verification will take approximately 50 minutes (100GB/2GB/min for esefile
verification). SnapManager backups should not be conducted while tape archives are being completed,
so the total time increment required between Snapshot operations is approximately two hours and 50
minutes (50 minutes for esefile verification plus 120 minutes for tape archiving to complete). Since only
four SnapManager backups are required per day, they can be evenly spaced out every six hours
without conflicting with the two-hour-and-50-minute tape archival process. The SnapManager backups
can also be strategically scheduled to occur at times of lighter Exchange usage: 7 a.m. is before the
main logon period of 9 a.m., noon is during lunch, 8 p.m. is after most people go home, and 11 p.m. is
the backup that will be archived to tape.
This strategy relies on the esefile verification speed and the time it takes to complete a tape archive.
Esefile verification times vary from one environment to another. In order to accurately predict esefile
verification speed, create a SnapManager backup of an Exchange 2000 server, mount the storage
group LUNs, and then time the esefile procedure against the database files (both .EDB and .STM). This
will allow accurate prediction of esefile speeds in your environment. Tape archival speeds usually can
be retrieved from tape software backup logs.
A volume containing a storage group set to be backed up can also contain Exchange storage groups
belonging to other servers. These storage groups constitute their own storage group sets, depending
18
TECHNICAL REPORT
on the Exchange server they belong to. To create a recoverable backup of the storage group, you must
use the SnapManager backup feature and explicitly configure that storage group as the backup target
to the Exchange server it belongs to.
SnapInfo Directories
The SnapInfo directory contains the information about each storage group backup set created by a
SnapManager backup. A subdirectory under the SnapInfo directory is created for each backup set and
contains the transaction logs backed up as part of that Snapshot operation as well as the recovery
information for that specific Snapshot duplicate. Every time a SnapManager backup is created, a new
backup set subdirectory is created under the SnapInfo directory and is populated with the appropriate
information and data. A complete backup set consists of this SnapInfo subdirectory and the
corresponding backup of the virtual disk drive that stores the Microsoft Exchange databases.
Note: The SnapInfo directory can be found on the virtual disk configured for the transaction logs. Do
not attempt to delete or move any of the files or folders found in the SnapInfo directory.
Tape Archive
The combination of SnapManager for Exchange and tape archives of SnapManager backup sets
provides a solid disaster recovery solution for Microsoft Exchange information store data. Please keep
in mind that information store data is only one piece of a complete Exchange disaster recovery plan. A
complete disaster recovery backup strategy must also include system-level backups of the Exchange
server as well as Active Directory domain controllers in the domain running Microsoft Exchange.
The recommended strategy for archiving SnapManager for Exchange backups requires two different
backup operations.
1. The first operation utilizes NDMP or dump for the storage group database Snapshot copies.
This will ensure the complete archive of the Snapshot backup containing the storage group
databases.
2. The second operation should use a CIFS-based or local backup of the LUN where the
transaction logs and SnapInfo directory are located. The archives should be generated off of
the most recent verified backup set of the entire Exchange server, ensuring all storage groups
and their associated log files are properly archived under the most recent Snapshot name.
NetApp recommends that the transaction log backup operation occur chronologically first, followed by
the database volume backup. This order of operations will reduce the amount of time when a tape
backup and a SnapManager backup may conflict due to the renaming of transaction log directories.
Archiving single storage groups from SnapManager backups is not recommended. This task requires a
full understanding of the Snapshot naming conventions used by SnapManager for Exchange and
should not be attempted without knowing which Snapshot backups contain the appropriate storage
groups and logs for a given point in time.
1. Create a SnapManager backup of the entire Exchange server (all storage groups).
19
TECHNICAL REPORT
2. Use NDMP or dump to back up the Snapshot files containing storage group databases.
o In this example, dump the volumes that are associated with drives G: and H:, which are
/vol/data2 and /vol/data3 on the eddie filer.
20
TECHNICAL REPORT
o The appropriate Snapshot copies to dump in this example with two storage groups
would be /vol/data2/.snapshot/exchsnap__tmw2k3__recent and
/vol/data3/.snapshot/exchsnap__tmw2k3__recent.
3. Use CIFS or a local backup program to back up the appropriate SnapInfo transaction log
directory or directories.
o Only the most recent SnapManager backup of the log files will need to be archived.
The naming convention for the appropriate directory using a CIFS-based backup is
\\Exchange_server_name\SnapInfo_LUN_Drive_Letter$\SnapInfo_Directory_Path
\Exchange_server_name\storage_group_name\Exchange_server_name__recent.
o This example used two storage groups, so both of the following directories will need to
be archived:
F:\NetApp SnapManager\SnapInfo\EXCH__TMW2K3\SG__First Storage
Group\TMW2K3__recent
F:\NetApp SnapManager\SnapInfo\EXCH__TMW2K3\SG__SG2\TMW2K3__recent
Other Exchange Backup Solutions
SnapManager for Exchange utilizes log files for full recoverability. The use of other vendor backup
utilities may inhibit the ability of SnapManager to recover data if the utility truncates log files after
completion. Make sure that any backup utilities used to back up Exchange while running in a
SnapManager for Exchange environment do not truncate log files.
Combining backup types against the Exchange database is not supported and will likely lead to loss of
data. Only SME backups should be performed against the Exchange databases. Other backup utilities
should still be used for the Windows system files and for the Windows system state data, including the
Active Directory information for disaster recovery purposes.
An up-to-the-minute restore can be performed using any available SnapManager backup as long as a
contiguous set of transaction logs exists that allows transactions to be played forward from the backup
time to the current point in time.
Regardless of the restore procedure that is chosen based on the situation, there are many important
factors to keep in mind regarding Exchange restores. All databases in a target storage group will be
dismounted at restore time. For Microsoft cluster environments, all resources on the virtual disk (all
storage groups on the same virtual server) are taken offline.
21
TECHNICAL REPORT
It is important not to try to start the Exchange virtual disk during the restore process. Any storage
groups that have been renamed cannot be restored using Snapshot copies created prior to the name
change. NetApp recommends performing a backup of the storage group immediately following any
major changes, such as renaming a storage group or database.
Disaster Recovery
While Snapshot provides protection against Exchange data corruption or virus infections, it does not
protect against a catastrophic hardware failure with the Exchange server or a problem with the
operating system. To protect against these potential issues, a standby server will provide the fastest
recovery option.
There are two methods available for a rapid recovery of Exchange data in the event of a disaster: a
standby recovery server using identical hardware and a standby recovery server using nonidentical
hardware. Although these methods sound similar, there are different steps required for each.
To implement a standby server using the same hardware, use identical hardware configured
with the same firmware updates, software, and applications as the Exchange host requires.
Either the standby server can be used to mount the hard drives from the original Exchange
server (if necessary), or it can be quickly built to act as the original Exchange server. In addition
to a recent Snapshot copy of the Exchange database and the SnapInfo directory, a copy of the
Windows system state on the Exchange server will be required.
The following is a high-level overview of the steps to take when recovering to a disaster
recovery server using identical hardware. Each organization should have these steps well
documented and tested prior to actually recovering a failed mail system.
1. Have an identical server with Windows 2000 prepared and assign a temporary computer
name.
5. Run Exchange 2000 setup using the disaster recovery mode switch (setup.exe
/DisasterRecovery). Install service packs using this mode as well.
7. Reconnect the LUN drives and use the database configuration wizard to update the
location of the Exchange databases.
22
TECHNICAL REPORT
8. Restore the Exchange databases using the latest Snapshot copies. Ensure the Exchange
services have started and the databases are mounted.
For organizations that cannot afford to implement a standby server using identical
hardware, the Exchange services can be moved to another available server that is not
identical to the Exchange host, allowing for quick recovery of the Exchange data. This
procedure includes many of the steps similar to using the identical hardware approach.
Moving Exchange to a different server requires resetting the computer account in the
domain prior to restoring the system state. You must also add the following registry key for
service pack builds:
HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup DWORD_NAME:
ServicePackBuild SP1 HEX_VALUE: 1268 SP2 HEX_VALUE: 1682 SP3 HEX_VALUE:
1869
Note: It is important in both methods to ensure the new Exchange server uses the IP
address of the original Exchange server to eliminate any possible problems or confusion.
While moving the Exchange services to nonidentical hardware is a cost-effective solution, implementing
a standby recovery server using identical hardware is the recommended solution. Identical hardware
will ensure compatibility with all components and allows for the option of mounting the hard drives from
the production Exchange server in the event something other than the hard drive fails in the Exchange
host. More information on both these procedures can be found in the Additional Resources section at
the end of this document.
The frequency of SnapMirror update events is determined by the frequency of SME backups.
SnapDrive triggers SnapMirror updates upon completion of a SnapManager backup procedure. The
SnapMirror maximum transfer rate can also be adjusted in kilobytes per second.
A destination updates the mirrored copy or replica of its source by "pulling" data across a LAN
or WAN when an update event is triggered by the source.
Consistent with the pulling nature of SnapMirror, relationships are defined by specifying
sources from which the destination filers synchronize their replicas.
23
TECHNICAL REPORT
Destination filers are identified on source filers by assigning destination filers privileges via the
"snapmirror.access" protocol access option or by inclusion in the snapmirror.allow file.
SnapDrive currently works with volume SnapMirror (VSM) only. Qtree SnapMirror (QSM) is not
supported.
As discussed earlier, SnapManager is integrated with SnapDrive, which interfaces directly with Network
Appliance filers using the iSCSI or FCP disk access protocols. SnapManager relies upon SnapDrive for
disk management, controlling Snapshot, and SnapMirror events.
Install (via CIFS setup) both filers into the same Windows domain as the Exchange
organization.
Configure the Exchange, SnapDrive, and SnapManager Win32 services to use the same logon
service account.
Make sure the SnapDrive service account has the "Log on as a service" right in the Windows
operating system (normally occurs during installation).
Verify that RSH commands work between the Exchange server(s) and both filers using the
specified service account.
24
TECHNICAL REPORT
Make sure the filer's SnapMirror schedule is turned OFF by assigning the "- - - -" value (four
dashes separated by spaces).
SnapMirror updates to the specified destinations will occur after the completion of every SME
backup.
SnapDrive and FilerView can be used to verify the successful completion and state of the
configured mirrors.
25
TECHNICAL REPORT
26
TECHNICAL REPORT
27
TECHNICAL REPORT
System monitoring can be used to track the total amount of data received and sent by the interface
using the "Bytes Total/sec" of the network interface object. Simply monitor this counter after initial
installation to derive a baseline. Then set an alert to be sent if traffic flow increases significantly over
the baseline average.
This task can be completed by using the FilerView utility built into Data ONTAP. This utility can be
started by pointing a Web browser to http://filername/na_admin. Next, click the FilerView link. FilerView
will start and will ask for the credentials of a filer administrator. Once logged onto FilerView, click the
Filer menu option on the left side of the screen. Then choose the Syslog Messages menu option.
28
TECHNICAL REPORT
Review the log on the right side of the screen for any issues that may require administrative action. For
more information on FilerView, refer to the Data ONTAP System Administrator's Guide.
Terminal Server
Microsoft Terminal Server is not recommended as a way of administrating SnapDrive or SnapManager
for Exchange. When creating virtual disks from a terminal server session, the drives can appear as if
they were not created or have been disconnected when in fact they are operating without errors. The
only way to fully resolve problems when using Terminal Server is to log out of the session (but do not
disconnect). NetApp recommends avoiding Terminal Server for server management when possible.
11) Summary
Network Appliance SnapManager for Microsoft Exchange is a complete data management solution that
provides backup and restore features using Snapshot technology. By reducing backup and restore
times, minimizing Exchange outages, and consolidating Exchange storage, SME delivers a cost-
effective solution for managing critical Exchange data.
In conclusion, the recommendations made in this paper are intended to be best practices for most
environments. This paper should be used as a set of guidelines when designing, deploying, or
administrating SnapManager for Exchange. To ensure a supported and stable environment, familiarize
yourself with the resources provided in this paper and involve an Exchange specialist if necessary.
29
TECHNICAL REPORT
30
TECHNICAL REPORT
31
TECHNICAL REPORT
exchange/exchange2000/proddocs/onlinebooks/disrec/default.asp
Microsoft KB article 266096: "Exchange 2000 Requires /3GB Switch When Using More than 1GB of
RAM"
http://support.microsoft.com/default.aspx?scid=kb;[LN];266096
Microsoft KB article 313707: "Exchange 2000 May Lose Network Connectivity under Heavy Load"
http://support.microsoft.com/default.aspx?scid=kb;[LN];313707
Microsoft KB article 318230: "How to Change the Exchange 2000 SMTP Mailroot Directory"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q318230
Microsoft KB article 297289: "How to Move Exchange 2000 to New Hardware and Keep the Same
Server Name"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q297289
* Snapshot metadata consumes a very small amount of disk space (32MB per terabyte).
© 2002 Network Appliance, Inc. All rights reserved. Specifications subject to change without notice. NetApp, the Network Appliance logo, FAServer,
FilerView, NetCache, SecureShare, SnapManager, SnapMirror, SnapRestore, and WAFL are registered trademarks and Network Appliance,
Network Appliance Inc. ApplianceWatch, BareMetal, Camera-to-Viewer, Center-to-Edge, ContentDirector, ContentFabric, ContentReporter, DataFabric, Data ONTAP,
EdgeFiler, HyperSAN, InfoFabric, MultiStore, NearStore, NetApp Availability Assurance, NetApp ProTech Expert, NOW, NOW (NetApp on the Web),
RoboCache, RoboFiler, SecureAdmin, Serving Data by Design, Smart SAN, SnapCache, SnapCopy, SnapDirector, SnapDrive, SnapFilter,
SnapMigrator, Snapshot, SnapSuite, SnapVault, SohoCache, SohoFiler, The evolution of storage, Vfiler, and Web Filer are trademarks of Network
Appliance, Inc. in the U.S. and other countries. All other brands or products are trademarks or registered trademarks of their respective holders and
should be treated as such.
32