SnapManager Backup uses Snapshot functionality to create online, read-only copies of the Exchange databases. After the selected storage groups are backed up, the transaction logs that are already committed to the databases captured in the backup are deleted. For more information, see the following topics:
Exchange storage groups (Stores) stored on a single volume that belong to the same Exchange server are referred to collectively as a "storage group set". When you select an Exchange storage group for backup, all storage groups composing its storage group set are automatically selected for backup.
SnapManager Backup backs up the complete set of storage groups--all of which constitute the storage group set--in parallel. (Thus, these storage groups share the same backup name and date-time stamp.)
Note
Even though the backup includes all storage groups in the storage group set, you can still restore the storage groups individually.
Although SnapManager supports individual database restore, the minimum unit of backup, or the smallest object you can back up, is an individual Exchange storage group.
Note
For easiest administration, it is best to back up all the storage groups in the same Exchange server at the same time.
SnapManager Backup performs backups at the volume level:
When a Snapshot copy is taken of a LUN for a SnapManager backup, the entire storage system volume is captured in that Snapshot copy. However, that backup is valid only for that Exchange server. If data from other Exchange servers resides on the same volume, it is not restorable from that Snapshot copy.
SnapManager performs backups in parallel on all LUNs that belong to the same Exchange server and share a single storage system volume. When a storage group set spans multiple volumes, the resulting backup set contains multiple database Snapshot copies but is still restorable as a single entity.
If the backup of some of the storage groups or databases in the storage group set fails, those in the set that were backed up successfully can still be restored. Because each database constitutes its own backup, or file, it is restored discretely, independent of backups of the others in its storage group set, even though the backup of all databases and storage groups in the set was performed by the backup job.
In a Windows 2000 Server environment, SnapManager Backup performs the following tasks when creating a backup. The list of tasks is performed in its entirety for each volume that contains files for the storage groups to be backed up. For example, if two separate volumes are involved, the task list is performed once for the first volume, then again for the second volume.
In a Windows Server 2003 environment, SnapManager Backup performs the following tasks when creating a backup. The list of tasks is performed in its entirety for each volume that contains files for the storage groups to be backed up. For example, if two separate volumes are involved, the task list is performed once for the first volume, then again for the second volume.
The transaction logs are backed up and truncated during this step.
When SnapManager for Exchange is used in conjunction with Microsoft Exchange Server 2003 on a Windows Server 2003, it uses the Microsoft Volume Shadow Copy Service (VSS) subsystem to provide backup and restore functionality. If, in this environment, the SnapInfo directory has been configured on the same volume as the transaction log, then a single SnapManager backup will create two Snapshot copies on that volume instead of just one:
Note
For VSS backups, the snapshot of the transaction log LUN is used instead of the snapshot of the snapinfo directory LUN to verify the integrity of the transaction logs in the backup during remote database verification operation.
When SnapManager uses VSS for backup and restore functionality and SnapInfo is on the same volume as the transaction log, this is expected behavior.
Suppose the SnapInfo directory is on the same LUN as the transaction log in an Exchange Server 2003 environment with Windows Server 2003. The console output shows that the transaction log volume contains Snapshot copies with the same name as the Exchange database Snapshot copy. Example:
Exchange database Snapshot copy. Example:
Volume netappnj1_logs
working...
date name
____________ ________
Jan 30 01:04 eloginfo__mailnj1__recent
Jan 30 01:00 exchsnap__mailnj1__recent
Jan 29 13:03 eloginfo__mailnj1_08-29-2006_13.00.00__daily
Jan 29 13:00 exchsnap__mailnj1_08-29-2006_13.00.00__daily
Jan 29 01:04 eloginfo__mailnj1_08-29-2006_01.00.00
Jan 29 01:00 exchsnap__mailnj1_08-29-2006_01.00.00
Jan 28 13:03 eloginfo__mailnj1_08-28-2006_13.00.00__daily
Jan 28 13:00 exchsnap__mailnj1_08-28-2006_13.00.00__daily
Jan 28 01:04 eloginfo__mailnj1_08-28-2006_01.00.00
Jan 28 01:00 exchsnap__mailnj1_08-28-2006_01.00.00
Jan 27 15:36 eloginfo__mailnj1_08-27-2006_15.30.15
Jan 27 15:30 exchsnap__mailnj1_08-27-2006_15.30.15
Jan 20 15:35 eloginfo__mailnj1_08-20-2006_15.27.35
Jan 20 15:27 exchsnap__mailnj1_08-20-2006_15.27.35
If you are not aware of the configuration details, you might expect to see only the eloginfo__ Snapshot copies and not the exchsnap__ Snapshot copies.
Note
Volume size is unchanged because the backup set still captures the same total number of changed blocks on the storage system even though we are using two Snapshot copies instead of one.
Copyright © 1994-2006, Network Appliance, Inc. All rights
reserved.
Part No. 215-01873_A0
File: bkpabou2.htm
Last updated: 28-Mar-2006 11:30:59