During a SnapManager backup operation, SnapManager archives transaction log files on the live file system to the SnapInfo directory. To optimize backup operations in which the storage group transaction log files and the associated SnapInfo directory are located on the same NTFS volume, SnapManager archives transaction log files to the SnapInfo directory by creating NTFS hard links instead of performing a file copy operation. This conserves storage system disk space and improves system performance during the transaction log archival phase of the backup operation.
See the following topics for more information:
A hard link is a directory entry for a file, and it serves as a file system-level shortcut to the file. An application can use a hard link like any other file name. Unlike an application-level link, all changes made to a file accessed using a hard link are applied automatically and transparently; any updates to the file contents are seen by all applications that access the file using a hard link. Unlike a symbolic link, a hard link cannot cross file systems; that is, a hard link created on one NTFS volume cannot point to a file in a different NTFS volume.
Every file can be considered to have at least one hard link. Within a given NTFS volume, a single file can have multiple hard links. This enables a single file to appear in multiple directories or to appear multiple times (under different names) within the same directory. Because all of the links reference the same file, multiple applications can open any of the hard links and modify the same file.
Note
The NTFS file system will not delete a file until all hard links to the file have been deleted.
When a hard link is created for an existing file on an NTFS volume, NTFS simply adds hard link information and a reference count to the file's directory entry at the NTFS level. Neither the original file nor the file-based reference (the application-level link) are duplicated. While the physical file remains intact in its original location, the same content can be accessed by two or more names. Because the file system is responsible for managing the various path names to a single physical content, using a hard link can conserve system resources and storage system disk space as compared to performing a standard file copy operation.
During a SnapManager backup operation, SnapManager archives transaction log files on the live file system to the SnapInfo directory. The transaction log files are needed for SnapManager restore operations at the later time.
When SnapManager uses a file copy operation to copy the transaction log files from the live file system to the SnapInfo directory, this method of transaction log archiving has the following effects:
SnapManager 3.2 supports an optimization feature for cases in which the backup operation archives transaction log files to a SnapInfo directory that resides on the same volume. To achieve this optimization, SnapManager archives transaction log files to the SnapInfo directory by creating NTFS hard links to the live transaction log files, without physically copying the log file.
After the SnapManager backup operation completes, Exchange truncates the transaction log files. However, the physical log files on the original location are not deleted, because the NTFS file system detects that other hard links to the files still exist. Instead, the original NTFS hard links to the live transaction log files are removed, and the links to the SnapInfo directory remain intact and available for access during SnapManager restore operations.
SnapManager automatically uses NTFS hard links to archive transaction logs if they reside on the same LUN as the SnapInfo directory.
Transaction log archival is logged differently in the SnapManager backup report, depending on which archival method is used.
If a transaction log file is archived by performing a file copy operation, the backup report entry is similar to the following:
Log file copying from:
L:\Program Files\Exchsrvr\mdbdata\E000000A.log
Log file copying to:
S:\SME_SnapInfo\EXCH__CLPUBS-WINSRVR3\SG__First Storage Group\CLPUBS-WINSRVR3__recent\Logs\E000000A.log
If the same transaction log file is archived by creating an NTFS hard link instead of performing a file copy operation, the backup report entry is similar to the following:
Log file:
L:\Program Files\Exchsrvr\mdbdata\E000000A.log
Archived to:
S:\SME_SnapInfo\EXCH__CLPUBS-WINSRVR3\SG__First Storage Group\CLPUBS-WINSRVR3__recent\Logs\E000000A.log
The primary reason that SnapManager supports multiple SnapInfo directories is to facilitate the use of NTFS hard links for archiving transaction logs, thereby conserving system resources and storage system disk space. The use of multiple SnapInfo directories also has the additional benefit of minimizing your exposure to the loss of backups in case the SnapInfo directory is lost.
The following paragraphs describe both of the benefits of configuring your Exchange data to use multiple SnapInfo directories.
The use of NTFS hard links to archive transaction logs can only be applied to backup operations in which the transaction logs reside on the same NTFS volume as the SnapInfo directory. If your SnapManager environment is configured with a single SnapInfo directory for all Exchange storage groups, SnapManager can still use NTFS hard links to archive transaction logs, but only if all transaction logs for all storage groups are located on a single LUN on the same volume as the SnapInfo directory.
In most SnapManager environments, however, the Exchange transaction log files are stored on multiple LUNs in multiple storage system volumes. In this configuration, the use of NTFS hard links to archive transaction logs requires a separate SnapInfo directory for each Exchange storage group, with each SnapInfo directory placed on the same NTFS volume as the Exchange transaction logs for that storage group.
Copyright © 1994-2006, Network Appliance, Inc. All rights
reserved.
Part No. 215-01873_A0
File: lunreqt6.htm
Last updated: 28-Mar-2006 11:30:55