Implementing snapshots for e-mail storage
				Here's a typical way to use snapshots for Microsoft Exchange 2000/2003. This configuration allows an Exchange administrator to restore the entire Exchange environment, individual mailboxes or even individual messages (using third-party software). The Exchange server is connected to a storage array using Fibre Channel (FC) or iSCSI, and has the ability to make snapshots of existing logical unit numbers (LUNs) available to other hosts. Nightly, software on the Exchange server creates a differential or full-copy snapshot. Once this process completes, the Exchange server or another host runs ESEFILE.EXE against the snapshot of the Exchange database to verify that it's free of corruption. Verification requires considerable host CPU resources and generates significant I/O on the storage. For large Exchange databases, it may make sense to offload this process to another server. The I/O load will also determine whether to use differential or full-copy snapshots. Using a differential snapshot for the verification process will impact the performance of the production data, since most of the data blocks referenced by the differential snapshot will be in the production LUN. The Mailbox/message recovery server is used to restore individual user mailboxes or individual messages from the snapshot. There are many tools that provide this ability, including CommVault Systems Inc.'s Galaxy Backup & Recovery for Microsoft Exchange 2000/2003, Kroll Ontrack Inc.'s PowerControls and Quest Software Inc.'s Aelita Recovery Manager for Exchange. All of these tools allow for the recovery of individual messages and mailboxes from a snapshot without having to use a recovery server.

Data recovery points
The most popular use of snapshots is to create more frequent recovery points to reduce the overall RPO beyond what can be achieved with tape-based solutions. This is the domain of the differential-copy snapshot.

With a SAN, creating several differential-copy snapshots throughout the day provides multiple recovery points. Instead of recovering the production database from tape and rolling 10 hours of logs forward, you may be able to recover the database from a 45-minute-old snapshot and roll the logs forward from that point. This assumes a logical corruption, not a physical loss of data. This example is not as straightforward as the NAS example. Here are several points to consider.

• How easy is it to create a consistent image of the application's data? For the snapshot to be useful, application data needs to be in a consistent state when the snapshot is created.
• Does the application have a "hot backup" mode? Most database-type applications have a "hot backup" mode that ensures data files and associated logs are in a state that allows them to be backed up cleanly. If the application doesn't have such a mode, it should be shut down for the data in the snapshot to be useful.
• What impact does the hot backup mode have on application performance? If the application's hot backup mode will have a significant negative effect on application performance, then a synchronous full-copy snapshot may be a better alternative.
• How long will it take to create the snapshot? If it takes 30 minutes to create the snapshot, it doesn't make sense to do a snapshot every hour. Ideally, snapshots should take only seconds.
• Are third-party software tools needed to create a consistent image? Sometimes third-party tools provide a better interface for coordinating snapshot creation. Often, the same effect could be achieved by writing custom scripts. If a packaged product meets the organization's needs, the ease of management typically outweighs the cost of purchasing the utility.v
• Will the data files need to be checked before they can be used in production? In many cases, this check can be done immediately after the snapshot is created. Consistency checks typically generate considerable I/O and CPU load. Ideally, the check is done by another host that connects to the snapshot.
• For large applications, will multiple snapshots need to be created at the same time and across several different storage devices? Large applications typically have several storage locations spread across SAN, NAS or locally attached disks. An analysis is required to determine how "synchronous" the snapshot creation associated with all of the storage locations needs to be. For example, document management systems typically have a database on a SAN or direct-attached storage (DAS) disk that stores the locations of documents. The documents may be stored on a NAS server. It's important that every document reference in the database snapshot have a corresponding document in the NAS snapshot. Otherwise, if the system is restored to a previous state using a snapshot, it will be necessary to verify that documents referenced in the database exist on the NAS device.