SnapManager and snapshots

About SnapManager and snapshots

A snapshot is a point-in-time, read-only copy of a LUN stored on a filer volume. SnapManager Backup uses snapshot functionality to create real-time, online, read-only copies of Exchange databases. A SnapManager backup can consist of several snapshots, depending on how your Exchange data is configured.

Note
You must always use SnapManager to manage SnapManager backups, rather than managing the associated filer snapshots using SnapDrive, VSS, or filer administration tools, such as the FilerView® interface.

When to use the different snapshot and backup methods

There are multiple ways to take snapshots 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-based backups should be performed using only SnapManager. Taking a snapshot of the Exchange databases from the filer 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 or backup methods can create restorable backups.

Tool used to create snapshot or backup	System state
Tool used to create snapshot or backup	Exchange online	All Exchange dbs dismounted	All LUNs disconnected
SnapManager Backup	OK	N/A	N/A
SnapDrive	invalid	OK	N/A
Exchange-aware Windows backup utility	OK (copy backup only)	N/A	N/A
Non-Exchange-aware backup utility	invalid	OK (copy backup only)	N/A
Filer tools	invalid	invalid	OK

Understanding snapshots

The following figure provides an example of how snapshots work.

Example

Suppose you take a snapshot of a file named file.txt that spans four disk blocks in the active file system. Initially, the snapshot 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 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. 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, plus the one new block. The snapshot 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; deleting file.txt from the active file system does not free any disk space until the snapshot is deleted.

Maximum number of snapshots you can retain

Data ONTAP^TM software allows a maximum of 255 snapshots per filer volume. Because SnapManager backups create snapshots, you must delete old SnapManager backups as they are no longer needed to avoid reaching the limit.

Note
The number of snapshots 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 snapshots on that volume.