Understanding SnapManager configuration rules for Exchange

This topic contains SnapManager configuration rules for Exchange data stores:

Exchange data store configurations enforced

The Configuration Wizard enforces the following rules when you are configuring your Exchange data store for SnapManager 3.2 for Microsoft Exchange.

Exchange databases

Exchange databases cannot share a LUN with databases from different storage groups, and they cannot share a LUN with transaction logs (even if they are from the same storage groups).

Note
All databases on a LUN are restored together. To be able to restore an individual database without restoring the rest of its storage group, that database must have its own LUN.

Exchange transaction logs

Transaction logs from different storage groups can share a LUN.

SnapManager SnapInfo directory

A SnapInfo directory can have its own LUN, or it can share a LUN with transaction logs. If you want to take advanage of NTFS hard links (described in Understanding transaction log archiving using NTFS hard links), the SnapInfo directory cannot share a LUN with Exchange databases.

SAN boot LUN

You cannot place database files, transaction log files, or a SnapInfo directory on a SAN boot LUN (a LUN configured as a boot device for a SAN host).

Exchange storage group system files

The Exchange storage group system files must be on a LUN containing the transaction log files for that storage group.

SnapManager versions prior to SnapManager 3.2 for Microsoft Exchange placed the storage group system files on a LUN that stores the Exchange databases in configurations that used VSS to backup Exchange. The Configuration Wizard in this version of SnapManager automatically moves storage group system files to the same LUN as the transaction logs if you to modify the database or transaction log location for that storage group.

Exchange data store configurations to avoid

Nothing should be stored on the Exchange LUNs except what SnapManager puts there. If you add more databases or move databases to different LUNs without using the Configuration Wizard, you can create an invalid configuration that could cause SnapManager backup or restore operations to fail.

Note
After adding or moving Exchange data stores, always run the Configuration Wizard. This ensures that the Exchange data stores are stored in valid locations so that SnapManager backup and restore operations can finish successfully.

Before you migrate your Exchange database and transaction log files to LUNs, note the following recommendations against certain invalid configurations that could be created outside of the SnapManager Configuration Wizard.

No other files on LUNs used by any database files

Do not manually store any directories or files (including system paging files) on the LUNs used for by the Exchange data store files (database files and transaction log files).

No other files on the LUN used by the SnapInfo directory

Do not manually store any directories or files on the LUN used by the SnapInfo directory.

No Exchange database files on a LUN that hosts mount points

Do not manually store Exchange database files on a LUN that hosts NTFS volume mount points. For more information, see Understanding SnapManager support for volume mount points.

Exchange data store configurations recommended

For best results, consider the following Exchange data store recommendations:

Use dedicated volumes for your Exchange data.
Do not place LUNs containing data from different Exchange servers in the same volume. This recommendation helps you to avoid the following problems:
- SnapManager backups created for another Exchange server on the same volume use up Snapshot copies for that volume but are only restorable for the Exchange server they were taken for.
- Conflicting backup schedules between the two Exchange servers can lead to creating "busy Snapshot copies".
Do not place LUNs in the storage system's root volume. The root volume is reserved for use by Data ONTAP.
For faster backups and restores, use the minimum number of LUNs required for your business and service level commitments. Unless individual database restoration is a requirement in your environment, group your databases .

Exchange message tracking in an MSCS configuration

When using Exchange message tracking with SnapManager in an MSCS configuration, locate the message tracking directory on a shared LUN that does not store a database.

How the message tracking directory location is specified

To create an Exchange virtual server in an MSCS configuration, you install the Exchange binaries on both nodes and then create a new System Attendant cluster resource. As part of creating the System Attendant cluster resource, Exchange prompts you to Enter [a] path to the data directory. Exchange places the new databases and other related files--including the SMTP and MTA queues, as well as the message tracking log and MS Search files (if configured)--on this path on a shared disk.

The effect of SnapManager Restore on a database LUN

Suppose the path you specify as the System Attendant cluster resource data directory is a shared LUN that is later also specified (using the SnapManager Configuration Wizard) as the LUN for an Exchange database. In this scenario, the Exchange message tracking log and the Exchange database are located on the same LUN.

SnapManager does not prevent this configuration, nor does this configuration pose an immediate problem. Later, however, when a SnapManager Restore operation is performed, the restore process brings the entire LUN back from Snapshot copy, complete with the desired database and an old copy of the message tracking log.

To avoid restoring an old message tracking log

To prevent a SnapManager Restore of a database from also restoring an old copy of the message tracking log, locate the message tracking directory on a shared LUN that does not store a database.

If your message tracking directory is already on a database LUN

If you have already created a System Attendant cluster resource with the data directory on a shared LUN that will also be used to store an Exchange database, you can move the message tracking location to a different location on a shared disk:

For a description of how to move the message tracking location in Exchange Server 2000, see Microsoft Knowledge Base article 317700.
For a description of how to move the message tracking location in Exchange Server 2003, see Microsoft Knowledge Base article 841089.