Using Snapshot copies

How Data ONTAP Snapshot copies work in an iSCSI or FCP network

Snapshots of applications running on a file system may result in the Snapshot copy containing inconsistent data unless measures are taken (such as quiescing the application prior to the Snapshot copy) to ensure the data on disk is logically consistent before you take the Snapshot copy. If you want to take a Snapshot copy of these types of applications, you must first ensure that the files are closed and cannot be modified and that the application is quiesced, or taken offline, so that the file system caches are committed before the Snapshot copy is taken. The Snapshot copy takes less than one second to complete, at which time the application can resume normal operation.

If the application requires a lot of time to quiesce, it might be unavailable for some amount of time. To avoid this scenario, some applications have a built-in hot backup mode. This allows a Snapshot copy or a backup to occur while the application operates in a degraded mode, with limited performance.

Data ONTAP cannot take Snapshot copies of applications that have the ability to work with raw device partitions. It is recommended that you use specialized modules from a backup software vendor tailored for such applications.

If you want to back up raw partitions, it is best to use the hot backup mode for the duration of the backup operation. For more information about backup and recovery of databases using NetApp SAN configurations, see the appropriate technical report for the database at http://www.netapp.com/tech_library.

How Snapshot copies are used in the SAN environment

Data ONTAP cannot ensure that the data within a LUN is in a consistent state with regard to the application accessing the data inside the LUN. Therefore, prior to creating a Snapshot copy, you must quiesce the application or file system using the LUN. This action flushes the host file system buffers to disk. Quiescing ensures that the Snapshot copy is consistent. For example, you can use batch files and scripts on a host that has administrative access to the storage system. You use these scripts to perform the following tasks:

Make the data within the LUN consistent with the application, possibly by quiescing a database, placing the application in hot backup mode, or taking the application offline.
Use the rsh or ssh command in the script to access the storage system and use the snap command create the Snapshot copy on the storage system (this takes only a few seconds, regardless of volume size or use).
Return the application to normal operation.

Snapshot scripts can be scheduled to run at specified intervals. On Windows hosts, you can use the Windows Task Scheduler. On UNIX hosts, you can use cron or other utilities. In addition, you can use SnapDrive to save the contents of the host file system buffers to disk and to create Snapshot copies. See the SnapDrive Installation and Administration Guide.

The relationship between a LUN and a Snapshot copy

When you take a Snapshot copy of a LUN, it is initially backed by data in the Snapshot copy. After the Snapshot copy is taken, data written to the LUN is in the active file system.

After you have a Snapshot copy, you can use it to create a LUN clone for temporary use as a prototype for testing data or scripts in applications or databases. Because the LUN clone is backed by the Snapshot copy, you cannot delete the Snapshot copy until you split the clone from it.

If you want to restore the LUN from a Snapshot copy, you can use SnapRestore, but it will not have any updates to the data since the Snapshot copy was taken.

What Snapshot copies require

In Data ONTAP 6.5 and later, space reservation is enabled by default when you create the LUN. This means that enough space is reserved so that write operations to the LUNs are guaranteed. The more space that is reserved, the less free space is available. If free space within the volume is below a certain threshold, Snapshot copies cannot be taken. For information about how to manage available space, see Chapter 9, Managing Disk Space."