Ezine

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.

Implementing snapshots for e-mail storage

    Requires Free Membership to View

    Login

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.

QA and debug
Quality assurance (QA) and debug environments benefit significantly from both full-copy and differential-copy snapshots. The following steps are typical of a QA/debug scenario:

  1. Create a dump of production data
  2. Copy dump to test bed
  3. Load dump data into test system
  4. Run through first pass of QA/debug tests
  5. Reload original dump data
  6. Repeat Steps 3 and 4 until done
  7. Repeat Steps 1 through 5 for next QA cycle

Many times, Step 1 represents only a portion of the production environment. This is because it would be too expensive to recreate the production environment, or loading the dump data into the test system takes too long. Using a combination of full-copy and differential snapshots, the process could change to the following:

  1. Update full-copy snapshot of production data
  2. Break mirror relationship
  3. Create a differential snapshot of full-copy snapshot data
  4. Load dump data into test system
  5. Create a differential snapshot of the test system configuration
  6. Run through first pass of QA/debug tests
  7. Restore test system to differential snapshot created in Step 5
  8. Repeat Steps 3 and 4 until done
  9. Repeat Steps 1 through 5 for next QA cycle

Eliminating the production system dump and multiple reloads of the dump data shortens the QA/debug cycle. This makes it easier to test using the full system data, and allows more tests to be completed in a shorter timeframe.

This was first published in December 2004

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top