Network Appliance, a pioneer and industry leader in data storage
technology, helps organizations understand and meet complex
technical challenges with advanced storage solutions and global
data management strategies.
SnapManager for Microsoft Exchange Best Practices
John Phillips and Adrian Simays, Network Appliance Inc. | 8/2003
| TR 3233
TECHNICAL REPORT
TECHNICAL REPORT
Network Appliance Inc.
1
TECHNICAL REPORT
Table of Contents1 2 3 4 5 6 7 8 9 10 11 12 13 Introduction
Exchange and Filer Design Preparing the Exchange Host (Windows
Server) and Filer Installing Network Appliance SnapDrive Software
Creating and Managing Virtual Disks with SnapDrive GUI Installing
and Configuring Network Appliance SnapManager for Exchange Snapshot
Backing Up and Restoring Exchange with SnapManager Using
SnapManager for Exchange with Network Appliance SnapMirror
Management Tools Summary Ethernet and FCP Technology Diagrams
Additional Resources 3 4 8 9 12 13 15 17 23 26 29 30 31
Network Appliance Inc.
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). Factors
That Affect Exchange Scalability Microsoft Exchange is considered a
mission-critical application by small and large companies alike. If
employees are not able to send and receive e-mail, access their
calendars, or retrieve contact information, it can be disruptive
and costly to businesses. 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. Network Appliance SnapManager 3.0 for Exchange Network
Appliance SnapManager for Microsoft Exchange enables Microsoft
Exchange to leverage the many powerful and specialized features
inherent in Network Appliance storage technology. 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
Network Appliance Inc.
3
TECHNICAL REPORT
Full integration with the Microsoft Volume Shadow copy Services
(VSS) snapshot API architecture when running Exchange 2003 on
Windows Server 2003 Greater data consolidation and scalability for
Exchange servers Network Appliance storage technology offers
industry-leading performance 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. 2) Exchange and Filer Design Planning Exchange and
Filer Use There are many factors to consider when designing a
Microsoft Exchange environment on a Network Appliance filer.
Important factors include volume sizing for Exchange data and
transaction logs, which include the number of disks per storage
volume and the placement of critical Exchange 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: 1. A volume, or collection of
physical disks, is created on the filer 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. 4. Exchange data is moved to or
created on the LUNs as configured by SnapManager for Exchange *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. Calculating Exchange Database Size To
ensure that you create volumes that meet the Exchange database
requirements, you must calculate the potential size of your virtual
disks. The following formula can help you calculate your Exchange
database size:
Network Appliance Inc.
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. The deleted item cache is 20% (calculated by
multiplying by 1.20). For 1000 users with 100MB, mailbox quota
(((1000 * 100MB) / 1.5) * 1.2) = 8000MB, or about 80GB 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). Calculating Exchange Transaction Log Size How much disk space
is required for your Exchange database transaction logs can be
calculated by estimating the number of transaction logs that are
generated on your server. To estimate how many transaction logs are
generated, note the number of transaction logs that accumulate in
the transaction log directory immediately before a backup. Use that
number to estimate how much disk space you need (you should do this
over a period of several days and use the maximum number). 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: ((200 * 5MB) *
(5 + 1)) = 6000MB, or about 6GB. 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
Network Appliance Inc.
5
TECHNICAL REPORT
files, the copy would consume only 500MB. 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.) Volume Sizing Recap Following the examples provided in
this section, one could estimate the volume size for the storage
group volume to be:Exchange storage group 80GB
Future growth accommodation 24GB Maximum storage group size
Snapshot copies Space reservation Total volume size 104GB 10GB
104GB 218GB*
* This number represents a single storage group containing 1,000
users with 100MB per mailbox.
Network Appliance Inc.
6
TECHNICAL REPORT
Following the examples provided in this section, one could
estimate the volume size for the transaction log volume to
be:Transaction log Snapshot copy 6GB
Daily Exchange transaction logs 500MB Space reservation Total
volume size 6.5GB 13GB*
* This number represents transaction logs for a single storage
group.
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.
Exchange File Placement Designing the placement of Exchange files
will be critical to the overall performance and the protection of
critical Exchange data. When configuring Microsoft Exchange in an
SME environment, the following Exchange files should be stored on
LUNs: Exchange storage groups containing private and public
databases Exchange transaction logs Exchange SMTP files (for
high-volume environments) When configuring SnapManager for
Exchange, it is important to place the Exchange databases and the
Exchange transaction log files on separate volumes. This is
recommended for both recovery and performance. If the databases and
log files are stored on the same volume and a catastrophic failure
occurs to the disks in that volume, all Exchange data will be
affected. For optimal performance, separate LUNs should be used for
each storage group. 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.
Exchange SMTP Mailroot Directories For high-volume Exchange
environments, performance can be improved by placing the
Exchange
Network Appliance Inc.
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. MSCS Quorum
Disk Requirement If the deployment will use the filer as a quorum
device, another LUN will need to be created in addition to those
created for the Exchange database and transaction log LUNs.
Microsoft recommends that Exchange virtual servers not own the
quorum device. Create an additional two-disk volume with a LUN
dedicated for the quorum resource. For more information on MSCS
clusters and Exchange, please see the Additional Resources section
at the end of this paper. Multiple Virtual Disks per Volume in
Exchange Although SnapDrive and Data ONTAPTM support multiple
virtual disks per volume, disaster recovery and performance should
be considered before implementing. Multiple LUNs stored on the same
volume could result in data loss for an entire Exchange
organization. If the Exchange database and transaction log files
are stored on the same volume and the volume becomes unavailable,
archived Snapshot backups will be the only way to restore the
Exchange environment. 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. 3) Preparing the Exchange Host (Windows Server)
and Filer There are several things that need to be done to prepare
a filer and the Exchange host for optimal performance and to
eliminate the possibility of error. Refer to the latest SnapDrive
and SnapManager for Exchange administration guides to ensure the
proper licenses and options are enabled on the filer. 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
Network Appliance Inc.
8
TECHNICAL REPORT
A qualified Gigabit or Fibre Channel host bus adapter (HBA)
target card for use with iSCSI or FCP 4) Installing Network
Appliance SnapDrive Software SnapDrive interfaces directly with
Network Appliance filers and the Microsoft Windows Server volume
manager to facilitate the management of virtual disks provisioned
on NetApp storage. Network Appliance SnapDrive software is composed
of a Win32 service, a Microsoft Management Console (MMC) Windows
management application, and the device drivers for iSCSI and 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. Resolve any hardware, cabling, or
network issues or other errors. Make sure all of the necessary
software and printed or electronic documentation (found on
http://now.netapp.com) are organized and nearby before beginning.
Configure DNS, host name, and IP addressrelated services: 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). Manually add the filers'
host names to DNS. Enable, configure, and test RSH access on the
filer(s) for administrative access (for more information, see the
Data ONTAP product documentation).
o o
License all of the necessary protocols and software on the
filer. 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).
Network Appliance Inc.
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. When using FCP, it is not necessary to install the
iSCSI drivers.
Figure 1) SnapDrive installation wizard
Network Appliance Inc.
10
TECHNICAL REPORT
Figure 2) SnapDrive service account 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.
Network Appliance Inc.
11
TECHNICAL REPORT
Microsoft Volume Shadow Copy Services (VSS) and SME 3.0 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.
SnapManager for Exchange and the VSS Architecture Volume Shadow
Copy Service Windows Server 2003 VSS Requestor NetApp SnapManager
for Microsoft Exchange VSS Writer Exchange Server 2003 VSS Hardware
Provider NetApp FAS200, FAS800 series, FAS900 series filers
5) Creating and Managing Virtual Disks with the SnapDrive GUI
Once installed, SnapDrive can be used to create LUNs on Network
Appliance filers for use by Windows 2003 and Windows 2000 hosts.
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. General Tips for
Creating LUNs: 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.
Network Appliance Inc.
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: filer> vol options voldata1
nosnap on
Figure 3) Specifying a virtual disk path Important Tips for
Using Fibre Channel: 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. 6) Installing
and Configuring Network Appliance SnapManager 3.0 for Exchange
General Info After following the steps outlined in the SnapDrive
3.x Installation Guide and as listed in the previous sections of
this paper, proceed with the installation of SnapManager for
Exchange. The SnapManager for Exchange program is a powerful tool
that allows for moving the Exchange database and log files as well
as controlling backup schedules and managing Snapshot. It is
important to protect access to SME, since the altering of Exchange
settings could produce undesirable results.
Network Appliance Inc.
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. SnapManager 3.0
for Microsoft Exchange in a Cluster Environment 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. Upgrading from
Exchange 5.5 During the upgrade from Exchange 5.5, the SnapManager
for Exchange 5.5 program cannot be upgraded to the latest version
of SnapManager for Exchange. If SnapManager for Exchange 5.5
exists, it must be uninstalled before SnapManager for Exchange 2000
can be installed. 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
Network Appliance Inc.
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) The
amount of time that elapses between creation of Snapshot copies The
measure of change (in megabytes, gigabytes, etc.) that occurs in
the file system between creation of Snapshot copies is called the
delta. The total amount of disk space required by a given Snapshot
copy equals the delta changes in the file system and a small amount
of Snapshot metadata.1 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). Snapshot Copies Created by
SnapManager for Exchange When SnapManager for Exchange creates
Snapshot backups, it names them according to the server name, date,
and time. The one exception is the most recent Snapshot copy, which
ends with "recent" instead of a date and time. When another
Snapshot backup occurs, it assumes the "recent" name, and the
former one is renamed to reflect its original date and time.
Exchange Database Snapshotexchsnap__tmlssrv1__recent 1% ( 1%) 0% (
0%) Jan 30 03:54 exchsnap__tmlssrv1_01-30-2003_03.43.15 2% ( 1%) 0%
( 0%) Jan 30 03:39 exchsnap__tmlssrv1_01-30-2003_03.31.34 3% ( 2%)
0% ( 0%) Jan 30 03:27 exchsnap__tmlssrv1_01-30-2003_03.18.29 14%
(11%) 0% ( 0%) Jan 30 03:14
Transaction Log Snapshoteloginfo__tmlssrv1__recent 0% ( 0%) 0% (
0%) Jan 30 03:54 eloginfo__tmlssrv1_01-30-2003_03.43.15 7% ( 7%) 0%
( 0%) Jan 30 03:39 eloginfo__tmlssrv1_01-30-2003_03.31.34 11% ( 5%)
0% ( 0%) Jan 30 03:28
eloginfo__tmlssrv1_01-30-2003_03.18.29
15% ( 4%)
0% ( 0%)
Jan 30 03:14
Mounting Snapshot Copies of LUNs for Write Access Snapshot
backups of the Exchange storage group databases are read-only
point-in-time images. This protects the data and guarantees the
integrity of the Snapshot backups. In certain situations an
administrator may require read/write access to the storage group in
a Snapshot copy to build a recovery or other server for testing
purposes. In this case write access rather than the need to
actually
Network Appliance Inc.
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.
Figure 4) Mounting a Snapshot backup from within SnapDrive.*
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. Issues When Mounting the "Recent" Snapshot Copy
The latest Snapshot backup is always the
exchsnap__servername__recent Snapshot copy. This can be confusing
if the former Snapshot backup was mounted while it was named as the
"recent" Snapshot copy. In this example, the mounted version of the
formerly "recent" Snapshot copy will continue to be labeled as such
as long as it's mounted. This is true even though it is no longer
the actual most recent copy and has been renamed to reflect the
date and time it was created. The change is not reflected in the
active mount.
Network Appliance Inc.
16
TECHNICAL REPORT
Disk Space Consumed by Read/Write Snapshot Copies Even though
read/write Snapshot files are initially linked to the existing
blocks in the Snapshot copy, it is necessary for the filer to
allocate blocks equal to the entire size of the file should it be
completely overwritten and a copy of it created. There must be
enough available disk space to accommodate the entire size of the
original LUN while the read/write Snapshot copy is mounted. The
space consumed by the read/write Snapshot copy is marked as free
disk space when it is dismounted using the Disconnect Disk command
within SnapDrive. 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. 8) Backing Up and Restoring
Exchange with SnapManager Recommended Settings Configuring a backup
schedule for Exchange data will vary from site to site based on the
requirements of the organization. Proper scheduling of SnapManager
backups requires consideration of the tape archival solution's
backup speed. SnapManager backups can be completed much more
quickly than tape solutions if esefile verification is not
conducted. This capability may tempt Exchange
Network Appliance Inc.
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:Tape
archives of the Exchange server desired: 1 per day Tape archive
time: SnapManager backups per day desired: Total storage group
size: 2 hours 4 (7 a.m., noon, 8 p.m., 11 p.m.) 100GB
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. Storage Group Sets A storage group
set is one or more Exchange storage groups that belong to the same
Exchange server and are stored on the same filer volume. When one
storage group on a volume is selected to be backed up, all the
others on that volume are automatically preselected. 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
Network Appliance Inc.
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. The appropriate steps to archive an entire Exchange server
are: 1. Create a SnapManager backup of the entire Exchange server
(all storage groups).
Network Appliance Inc.
19
TECHNICAL REPORT
Figure 5) Creating a SnapManager backup for the Exchange server.
2. Use NDMP or dump to back up the Snapshot files containing
storage group databases. o The naming convention for the
appropriate Snapshot file to archive is
/vol/LUN_volume_name/.snapshot/snapshot_name.
Figure 6) Viewing LUN locations in Computer Manager. 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.
Network Appliance Inc.
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.
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. Restore Best Practices
When restoring a Snapshot backup to a production Exchange
environment, there are two choices available to the administrator.
A point-in-time restore allows a restore to be made at a specific
point in time, taking the Exchange environment exactly as it was
when the backup was created. If the last backup was performed the
night before at midnight, the restore will bring the Exchange
system online reflecting the way it looked at midnight the night
before. 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. Renaming Storage
Groups
o
Network Appliance Inc.
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. 2. Ensure this server is a
member of a workgroup instead of a domain. 3. Important: Ensure the
original Exchange server is not online. 4. Restore the system state
data to the preconfigured Windows server. 5. Run Exchange 2000
setup using the disaster recovery mode switch (setup.exe
/DisasterRecovery). Install service packs using this mode as well.
6. Reinstall applications such as SnapDrive, SnapManager for
Exchange, and antivirus solutions. 7. Reconnect the LUN drives and
use the database configuration wizard to update the location of the
Exchange databases.
Network Appliance Inc.
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. 9) Using SnapManager for Exchange with
Network Appliance SnapMirror Network Appliance SnapMirror
technology mirrors data to one or more Network Appliance filers
over a local area network (LAN) or wide area network (WAN). Once
source and destination relationships are established, a SnapMirror
baseline transfer initializes the mirror to create a replica of the
source on the destination. SnapMirror maintains the synchronization
of the replica through efficient, incremental updates. Thus
SnapMirror is highly effective and efficient in its use of valuable
bandwidth, as it does not repeatedly send the entire LUN. 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.
Key SnapMirror Concepts and Tips: SnapMirror relationships are
based on sources and destinations. 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.
Network Appliance Inc.
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.
Figure 7) SnapManager and SnapMirror Components Checklist for
Configuring SnapManager and SnapMirror: 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. License and enable
FCP and/or iSCSI on both filers. License and enable SnapMirror on
both filers. Establish SnapMirror relationships.
Network Appliance Inc.
24
TECHNICAL REPORT
Make sure the filer's SnapMirror schedule is turned OFF by
assigning the "- - - -" value (four dashes separated by spaces).
Initialize the mirror configurations. 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.
Network Appliance Inc.
25
TECHNICAL REPORT
Figure 8) SnapMirror Status in FilerView 10) Management Tools
Snapshot Reserve Usage Monitoring The task of monitoring the
Snapshot reserve is automatically configured at the time of LUN
creation. Simply monitor the application event log for warning
events generated in the SnapDrive source and Snapshot monitor event
category. Figure 9 demonstrates that due to Snapshot consumption,
the reserve must be expanded to 63%, and there is not enough disk
space to do so. In order to rectify such a situation, either add
more disks to the volume or remove some of the oldest SnapManager
for Microsoft Exchange 2000 backups.
Network Appliance Inc.
26
TECHNICAL REPORT
Figure 9) LUN error due to space limitations. Disk Space Usage
Monitoring The amount of disk space used by Exchange should be
monitored to ensure that the logical drives (LUNs) containing data
do not run out of space. Exchange 2000 includes a monitoring
function that can be used to notify administrators of low disk
space. To enable this functionality for the LUNs, navigate to the
Tools | Monitoring and Status | Status section of the Exchange 2000
System Manager. Create an entry for each LUN with the appropriate
thresholds for your installation. The example shown in Figure 10
will monitor both the database (F:) and log (G:) drives for low
disk space conditions. (A warning is sent when the available space
drops below 2GB, and a critical state message is sent when the
drive is below 1GB.)
Network Appliance Inc.
27
TECHNICAL REPORT
Figure 10) Monitoring virtual disks in Exchange. Monitoring NIC
Utilization in Single-Homed Configurations NetApp recommends
monitoring NIC card traffic utilization as a best practice.
However, when the single-gigabit NIC deployment model is
implemented, this task is required. Monitoring the NIC utilization
is necessary in this deployment model because Exchange client,
Exchange database, and all other network traffic can be seen by the
single-gigabit interface. Malicious network attacks or broken
network equipment may cause enough traffic to affect Exchange
performance. 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. Filer Event Monitoring Monitor the filer
event logs to ensure proper operation of the filer. Issues may be
discovered in the event logs that require administrative action.
One such action may be to replace a disk in a volume if spare disks
are not available. 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.
Network Appliance Inc.
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.
Figure 11) Syslog messages in FilerView.
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 costeffective 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.
Network Appliance Inc.
29
TECHNICAL REPORT
12) Ethernet and FCP Technology Diagrams
Network Appliance Inc.
30
TECHNICAL REPORT
13) Additional Resources TR 3124: Integrating NetApp Filers with
the Microsoft Active Directory
www.netapp.com/tech_library/3124.html Exchange 2000 Documentation
and Release Notes www.microsoft.com/exchange/techinfo/productdoc/
2000/E2Kdocumentation.asp Exchange 2000 Deployment Guide
www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/exchange2000/
deploy/upgrdmigrate/ex2kupgr/deploy/default.asp Chapter 9 of
Exchange 2000 Deployment Guide, "Tuning Exchange for Performance"
www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/
exchange/exchange2000/deploy/upgrdmigrate/ex2kupgr/deploy/d_09_tt1.asp
Exchange 2000 Planning Guide
www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/
exchange/exchange2000/deploy/upgrdmigrate/ex2kupgr/planus/default.asp
Exchange Up-to-Date Web Site
www.microsoft.com/exchange/techinfo/deployment/2000/E2Kuptodate.asp
Deploying Exchange 2000 Clusters
www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=
824A63A2-F722-4BFF-A223E71B856F83C4 Disaster Recovery for Microsoft
Exchange 2000 Server
www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/
Network Appliance Inc.
31
TECHNICAL REPORT
exchange/exchange2000/proddocs/onlinebooks/disrec/default.asp
Exchange 2000 Top 50 Issues and Solutions
http://support.microsoft.com/default.aspx?scid=/support/exch2000/e2khottopics.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 298064: "Scalability Planning for Exchange
2000 Server"
http://support.microsoft.com/default.aspx?scid=kb;[LN];298064
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).
Network Appliance, Inc. Company Confidential and Proprietary.
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, 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.
Network Appliance Inc.
32