Tips for using SnapManager Backup

Importance of the initial backup

At the end of the database and transaction log migration process, SnapManager prompts you to make an immediate backup of the Exchange databases. Making an immediate backup of the Exchange databases is critical because previous backups are not valid.

Recommendations for scheduling backups and verifications

The more often you create SnapManager backups, the fewer Exchange transaction logs there are to be played forward at restore time, resulting in a faster restore. However, for best results, observe the following recommendations for scheduling backups and verifications:

Do not schedule any SnapManager operations to overlap each other.
Only one SnapManager operation can be running on the same machine at the same time.
Do not schedule a backup to occur while a verification is being performed, even if the verification is performed on a remote verification machine.
This can result in a backup that cannot be deleted easily. For more information about this problem, see Problem deleting backups due to busy snapshot error.
Do not schedule verifications on the Exchange server during peak usage hours.
The verification process is CPU-intensive and could degrade Exchange performance if run on the Exchange server during peak usage hours.

An easy way to conform to the preceding recommendations is to schedule your backups to occur during peak usage hours, and then use the off-peak hours to perform verifications.

Note
If you are scheduling backups in a Windows cluster, schedule them on only one node. If the Exchange virtual server fails over to another node, the node that takes over that virtual server performs the backup as scheduled. If the entire node fails, you need to set up the backup schedule again.

Backups during cluster failovers

If a Windows cluster move group or a filer cluster failover occurs during a SnapManager backup, the backup fails, and you need to restart the backup after the move group or failover is complete.

Using the page zeroing and deleted item retention Exchange features

Exchange includes the following two optional features that depend on the complete read of every database page during a backup:

Page zeroing
Used by high-security installations, this feature provides the ability to zero out database pages that were deleted.

Note
This feature is not available for Exchange 5.5.
Deleted item retention
This feature enables you to mark items for deletion after they are backed up.

Because SnapManager uses snapshot technology, and therefore does not read every page during a backup, these features are not triggered when only SnapManager is used to perform backups.

Note
The deleted item retention feature is invoked when you run SnapManager on a host system running Windows Server 2003.

You can cause these Exchange features to be triggered by scheduling a periodic backup using a standard backup utility, such as NTBackup.

Caution
Make sure that the backup you use for this purpose is a copy or differential backup. Performing any other type of backup causes existing SnapManager backups to become unusable for up-to-the-minute restores.

In addition, make sure that the extra backup is not performed at the same time as a SnapManager backup.

What to do if your SnapManager backup fails

If your SnapManager backup fails, check the backup report for details about what SnapManager was trying to do when the failure occurred. You can also review the following list of common backup failures:

Snapshot limit reached
If any of the volumes containing the LUNs being backed up reach the snapshot limit of 255, whether those snapshots were created by SnapManager or not, SnapManager backup fails. For more information about the snapshot limit, see Maximum number of snapshots you can retain.

Note
Automatic backup deletion is performed only after a successful backup is complete. Therefore, you must be able to create new snapshots before you begin a new backup procedure.
SnapInfo directory being accessed
Because a SnapManager backup might include renaming a SnapInfo subdirectory and Windows does not allow a directory name to be changed while it is being accessed, accessing the SnapInfo directory with a tool like Windows Explorer could cause the backup to fail. Make sure that you do not hold any exclusive access to the SnapInfo directory on the Exchange host when a backup is performed.
SnapInfo directory out of space
Expand the LUN that contains the SnapInfo directory.

Note
When you expand a LUN, make sure that sufficient space remains in the volume for snapshot creation, so that SnapManager can continue to function correctly. For more information about volume sizing, see Volume size calculation.
"Data does not match" error
You made changes to your Exchange data store since SnapManager was started. You can refresh your view by pressing F5, or you can restart SnapManager.
"Busy snapshot" error
If you initiate a backup when a LUN backed by snapshot exists, the result is a snapshot that cannot be deleted; when you try, you get a "busy snapshot" error and Event 249 is logged by SnapDrive in the event log. This can cause SnapManager backups to fail.

For information about recovering from this error, see Problem deleting backups due to busy snapshot error.
Snapshot already exists
- The system clock on the host running SnapManager might not be synchronized with the clock on the filer. These two clocks must be synchronized in order for SnapDrive to function correctly.
- If a SnapMirror replication is running when you attempt to initiate a SnapManager backup, the backup can fail. You can avoid this problem by making sure that any SnapMirror replications have enough time to complete before you initiate another SnapManager backup.
SnapManager server initialization failed
Either of the following circumstances might cause this error to occur:
- You have exited the SnapManager application, but SnapManager.exe or smesrvr.exe processes are still running. To correct this problem, terminate any orphaned SnapManager processes.
- The permissions associated with the SnapManager service account, or the service account itself, have been changed. In this case, SnapManager might not function correctly.

What the minimum unit of backup is

Although SnapManager 3.1 for Microsoft Exchange supports individual database restore, the minimum unit of backup, or the smallest object you can back up, is an Exchange storage group. SnapManager enables you to back up individual storage groups, but for easiest administration, it is best to back up all the storage groups in the same Exchange server at the same time.