This section describes how SnapManager works with the other system components. See the following topics for more information:
The following diagrams show how SnapManager interacts with other components of an Exchange installation backed by a NetApp storage system, for the Windows 2000 Server and Windows Server 2003 environments.
SnapManager is an Exchange-aware application that uses the Exchange backup APIs (for Exchange servers running Windows 2000 Server) or VSS (for Exchange servers running Windows Server 2003) to provide backup and restore functionality in an Exchange environment.
SnapDrive integrates with the NTFS Windows file system, Windows Volume Manager, and LUNs to enable the management of storage resources on the storage system in the Windows environment. SnapDrive provides the underlying layer of support for SnapManager.
You use SnapManager for all backups and related operations. For example, you use SnapManager to establish your Exchange databases on LUNs on a storage system and to back up and restore LUNs on the storage system.
You use SnapDrive only to create and manage the LUNs and storage system volumes that contain your Exchange data and to perform supplemental mirror updates of the transaction log volume when SnapMirror is used.
Microsoft Volume Shadow Copy Service (VSS) is a new feature of Microsoft Windows Server 2003 that coordinates between data servers, backup applications, and storage management software to support the creation and management of consistent shadow copies, or Snapshot copies. The Data ONTAP VSS Hardware Provider integrates the SnapDrive service and NetApp storage systems running Data ONTAP into the VSS framework. For more information about VSS, see your Data ONTAP VSS Hardware Provider documentation.
In the Windows Server 2003 environment, SnapManager is a VSS requestor, which means that it uses the VSS subsystem to initiate backups.
Although SnapManager uses VSS to create Snapshot copies, you manage the resulting Snapshot copies using SnapManager or SnapDrive. You cannot use the VSS administration tool vssadmin to manage Snapshot copies created by SnapManager.
Because SnapManager uses VSS to create Snapshot copies on the storage system in the Windows Server 2003 environment, you must have the Data ONTAP VSS Hardware Provider installed for SnapManager to function properly. For more information about the Data ONTAP VSS Hardware Provider, see your Data ONTAP VSS Hardware Provider documentation.
A Snapshot copyis a point-in-time, read-only copy of a LUN stored on a storage system volume. SnapManager Backup uses Snapshot functionality to create real-time, online, read-only copies of Exchange databases. A SnapManager backup can consist of several Snapshot copies, depending on how your Exchange data is configured.
Note
You must always use SnapManager to manage SnapManager backups, rather than managing the associated storage system Snapshot copies using SnapDrive, VSS, or storage system administration tools, such as the FilerView® interface.
There are multiple ways to take Snapshot copies or backups in an Exchange installation that includes SnapManager. It is important to understand when each of these methods can produce a restorable image and when they cannot.
When one or more Exchange databases are mounted, Snapshot copy-based backups should be performed using only SnapManager. Taking a Snapshot copy of the Exchange databases from the storage system console, FilerView, SnapDrive, or a non-Exchange-aware Windows backup utility results in an inconsistent image of the Exchange database that is unusable for a restore.
The following table illustrates when each of the Snapshot copy or backup methods can create restorable backups.
The following figure provides an example of how Snapshot copies work.
Suppose you take a Snapshot copy of a file named file.txt that spans four disk blocks in the active file system. Initially, the Snapshot copy version of file.txt and the version in the active file system are identical: the same blocks on disk store both versions, so the Snapshot copy version of file.txt consumes no additional disk space.
Now suppose that you make a modification to file.txt that affects only one of the four disk blocks. The new data cannot overwrite the original block because that block is needed as part of the Snapshot copy. So the new data is written to a new disk block and the file's inodes are updated accordingly. The active file system inodes now reference the three original disk blocks that have not been touched since the Snapshot copy, plus the one new block. The Snapshot copy inodes still reference the original four blocks.
If you delete file.txt, the blocks holding its data are no longer part of the active file system, but they are still part of the Snapshot copy; deleting file.txt from the active file system does not free any disk space until the Snapshot copy is deleted.
Data ONTAP® software allows a maximum of 255 Snapshot copies per storage system volume. Because SnapManager backups create Snapshot copies, you must delete old SnapManager backups as they are no longer needed to avoid reaching the limit.
Note
The number of Snapshot copies on a volume can be greater than the number of SnapManager backups being retained. For example, if a single volume contains both the SnapInfo directory and the Exchange databases, each SnapManager backup generates two Snapshot copies on that volume.
Copyright © 1994-2006, Network Appliance, Inc. All rights
reserved.
Part No. 215-01873_A0
File: overvie3.htm
Last updated: 28-Mar-2006 11:30:50