This article can also be found in the Premium Editorial Download "Storage magazine: How does your storage salary stack up?."
Download it now to read this article plus other related content.
|Application integration enhances snapshot value|
Full-copy snapshots are the obvious choice for DR; however, differential-copy snapshots can play a role. There are two update methods for a DR site: asynchronous and synchronous. Asynchronous updates are less expensive and can be as simple as shipping backup tapes to a remote site. Synchronous updates are typically reserved for the most critical applications. The disadvantage of synchronous replication is that it replicates a corrupted database as quickly as it does a clean database. Differential snapshots can be used at both the DR site and the production site. In the event the primary site becomes unavailable, and/or the data set is corrupted, a rollback could be performed at either the DR or production site.
An additional advantage to using differential snapshots at the DR site is that one of these snapshots could be used as the basis of a tape backup. That way, the production data is kept synchronous and a point-in-time image of the data can be sent to tape without requiring a third copy of the data.
Here is one way to use snapshots in a NAS storage environment with, for example, a data center and two remote sites. The two remote sites use differential-copy snapshots to provide seven days' worth of local file recovery. Five hourly snapshots are created during the day to allow the user to recover files lost the same day they were created. Each night, a full-copy snapshot is replicated to the data center. This full-copy snapshot would send only the blocks of data that have changed at the remote site since the last update to the data center. The NAS device at the data center is used as the source of the tape backup. This lets you eliminate tape backup systems at the remote sites for the data stored on the NAS devices. The NAS device at the data center also keeps 30 differential snapshots of the remote site data. This combination allows files to be recovered directly from disk for a period of 30 days. Any data older than 30 days would have to be recovered from tape.
This scenario also provides a DR location for the remote site data. In the event of a disaster, users could be redirected to the data center. The ease of doing this depends on how users access the local NAS data. The redirection can happen almost transparently using Microsoft's Distributed File System (DFS) in the Windows space. For Unix clients, a combination of Domain Name System (DNS) updates and IP aliases can achieve similar results.
Many NAS devices allow self-directed restores. In this case, users have access to the snapshot file system and can recover files on their own. Most organizations, especially large ones, tend to keep this information from their users because of the confusion it may introduce. Additionally, each NAS device has its own access method and naming conventions for snapshots. In a multivendor environment, the user education process would not be worth the effort. With the release of Microsoft Shadow Copy Client, this may change. The Shadow Copy Client provides a common recovery interface for NAS snapshots through the familiar Properties dialog box. When this client is installed, a new tab labeled Previous Versions is shown when the properties of directory or file are displayed on a network drive. This interface is currently supported by Windows 2003 and NetApp NAS devices when used in conjunction with a Windows desktop client.
Using snapshots in a in a database environment allows a database administrator to roll back a production database to one of several recovery points during the day. The storage at a secondary site is used for QA and DR, and forms the basis of the nightly tape backup.
The choice of using differential snapshots at the primary site depends on the update and delete rate associated with the database. A high rate of changes and deletes may force the use of full-copy snapshots. As with all applications, the performance impact of using differential snapshots needs to be understood prior to implementation. If asynchronous updates are going to the secondary site, the updated interval should be coordinated with the differential snapshot schedule at the primary site. This reduces the amount of time the database needs to be in hot backup mode.
Coordinating snapshots to support critical applications that typically span multiple servers, operating systems and storage systems can be daunting. But the big win may be with mid-tier applications, which often require far less analysis to determine the impact of snapshots and may use only tape for recovery.
This was first published in December 2004