How SnapManager for Microsoft SQL Server works

This section describes how SnapManager works with the other system components. See the following topics for more information:

System overview

SnapManager is an SQL Server 2000- and 2005-aware application that provides backup and restore functionality in an SQL Server environment.

Relationship with other components of an SQL Server installation backed by a storage system

The following illustration shows the relationship between storage systems, SnapDrive, and SnapManager 2.1 for Microsoft SQL Server.

Relationship with SQL Server components

SnapManager 2.1 for SQL Server is installed on an SQL Server computer running Windows 2000 Server or Windows Server 2003. SnapManager is an SQL Server 2000- and SQL Server 2005-aware application that uses the SQL Server VDI API and the SQL Distributed Management Objects (SQL-DMO) to provide backup and restore functionality in an SQL Server environment, as shown in the following illustration.

How SnapManager and SnapDrive work together

SnapDrive integrates with the NTFS Windows file system and the Windows Volume Manager to enable the management of the LUNs on a storage system in a Windows environment. SnapDrive provides the underlying layer of support for SnapManager by making these LUNs available as local disks on the Windows host system.

When to use SnapManager

Having SnapDrive installed on the SQL Server is a requirement for using SnapManager. After SnapDrive is installed and your LUNs are created, you can use SnapManager to migrate SQL Server databases from local disk to LUN and perform backups and restores using Snapshot technology.

When to use SnapDrive

SnapDrive manages LUNs on a storage system, making these disks appear available and as ordinary local disks on the Windows host server. This enables the server to interact with the LUNs as if they were directly attached, physical disks. You can use SnapDrive to create, connect, expand, and manage LUNs. For information about how to perform these tasks using SnapDrive, see the SnapDrive Installation and Administration Guide for your version of SnapDrive.

How SnapManager works with other backup methods

NetApp recommends that you employ SnapManager technology as a complement to conventional backup processes.

Supplementary backup archive

SnapManager backups are not intended to replace data archiving schemes in place for long-term or permanent data retention. Because SnapManager backups reside on primary disk, you should move your data to alternative media locations, such as a NearStore system or some other type of secondary storage media. NDMP or the storage system dump command are the most efficient methods for creating archives of the LUN drive files.

Enterprise Manager or Management Studio backup utility

Because some types of third-party backup applications truncate transaction logs and interfere with the SnapManager for SQL Server recovery process, you should not perform transaction log backups with any application other than SnapManager for SQL Server.

What SnapManager does not back up

SnapManager does not back up all the files commonly used by an SQL Server computer. You can use NTBackup (a native backup utility that ships with Windows) to back up the system state and the file systems on hard disks connected to the SQL Server.

Note
You can use NTBackup to archive SnapManager backup sets to a file, instead of using tape, and store that file on a storage system.

How SnapManager works with Snapshot copies used as backups

A Snapshot copy is a point-in-time, read-only copy of an SQL database stored on a storage system volume. SnapManager Backup uses Snapshot functionality to create real-time, online, read-only copies of the SQL database. Snapshot copies enable you to restore your SQL database rapidly if you encounter data corruption or other problems.

The following illustration provides an example of how Snapshot copies work.

Example

Suppose you make a Snapshot copy 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 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. As a result, 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 modified 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.

How the storage system safeguards data

Under SnapManager, the SQL Server data and log files reside on a LUN created on the storage system and formatted with the New Technology File System (NTFS).

The storage system is a volume manager that stores LUNs. The storage systems use battery-protected nonvolatile RAM (NVRAM) to protect incoming file system I/O operations. The contents of NVRAM are flushed to disk at regular intervals--more frequently if the NVRAM fills up, even during periods of inactivity. This ensures that the file system is always in a consistent state. The storage system guarantees that the contents of NVRAM are always written to disk, even during a power failure.