Exchange Server 2003 and VSS

The increasing importance of messaging and collaboration as mission-critical services has left Microsoft Exchange Server administrators and implementers looking for new ways to improve server recoverability and availability. In addition, hardware and software vendors are supporting technologies that enable more rapid recovery of server data and applications. Two specific enabling technologies are volume snapshots and volume cloning. These technologies are available in a variety of hardware and software implementations ranging from full-blown snapshot-manager products for Exchange to integration kits for a custom Exchange recovery solution. In the past, regardless of how these technologies were delivered, Microsoft products didn't support snapshots or cloning. Table 1, page 52, lists pertinent Microsoft articles that discuss snapshot and cloning support for Exchange 2000 Server, Exchange Server 5.5, and Exchange 4.0. However, with the advent of Windows Server 2003 and Exchange Server 2003, Microsoft has introduced Volume Shadow Copy Service (VSS), which makes snapshots and cloning available natively to Exchange administrators. Let's look at VSS and what it means to Exchange disaster recovery and availability.

Volume Snapshot and Volume Cloning Overview
Let's briefly review volume snapshots and volume cloning. Although these technologies aren't new, they're relatively new to the Windows platform. Cloning and snapshot technologies provide Business Continuance Volumes (BCVs)—a mechanism for data duplication and point-in-time copies. On the surface, these technologies might appear to be the same; however, they're quite different in technical implementation.

Volume snapshots. A volume snapshot (also known as a copy-on-write snapshot) is a representational metadata mapping of specific volume blocks at the time you create the snapshot. For example, if you create a snapshot of your Exchange database volume, the snapshot represents the blocks on disk that compose your Exchange database and any other files on the volume at the time you create the snapshot. Therefore, after you create a snapshot, you must maintain the original volume blocks for the snapshot to remain intact. As a result, you must copy changes to the volume blocks to another location in the storage pool. From an Exchange viewpoint, this requirement means that if you create a snapshot for the volume on which Exchange data resides, then make a change to a page in the Exchange database, the VSS-supported storage system will typically copy the affected blocks to a special "diff" area in the storage pool allocated from free volume pool space. In this manner, the system preserves the original subset of volume blocks that represent the snapshot. After you create the snapshot, the production data consists of a combination of original unchanged blocks from the snapshot and new blocks of data. The snapshot remains intact and represents the data state at the time the snapshot was created. Creating snapshots is relatively quick and simple—the VSS-supported storage system creates the volume block mapping, and the snapshot exists. Because a copy-on-write snapshot isn't a complete redundant copy of the data and is subject to disk failures, this technology is less desirable than clones. As a result, snapshot recovery can be problematic if the base volume is lost or corrupted because an administrator must complete several steps to recover the original volume.

Volume clones. Similar to volume snapshots, volume cloning isn't a recent development. Cloning comes from RAID 0+1 technology. A clone is an additional member of a RAID 0+1 mirror set. For example, if you have a RAID 0+1 set with three disks mirrored to three disks, you have a two-member RAID 0+1 set. By normalizing another three disks to the existing RAID 0+1 set of six disks, you create a three-member mirror set (i.e., a triple mirror of nine disks). You can add other members to the mirror set as well. By creating multimember mirror sets and then separating members from the set, you enable clones. Because the existing production data has multiple mirrored copies, you can use some of these copies to create point-in-time copies of the data. Unlike a snapshot, a clone is a complete standalone copy of the data. To create a clone, you simply separate one or more members of the RAID 0+1 mirror set from the production set. The result is a production mirror set that supports the application (i.e., the two-member RAID 0+1 array) and clones (single-member sets) that you've separated from the production data, as Figure 1 shows. In the event of data corruption or loss, you can use a clone to recover system data by making the clone available as the production LUN. Because clones are a complete redundant copy of the data, they're most useful as rapid-recovery mechanisms.

The advantage of volume clones lies in how quickly you can create them. The downside is having to resynchronize an old (or new) member with the primary mirror set, which can take time depending on the size of the disks and the capabilities of the controller and enclosure.

The VSS Foundation
Because volume snapshots and volume cloning have had limited availability in the Windows space, the OS and applications haven't been able to take full advantage of these technologies. Hardware and software developers have implemented snapshot and clone solutions with little or no exposure or integration with the OS and applications. As a result, third-party vendors have been primarily responsible for supporting these solutions.

Microsoft has made substantial storage technology investments, including VSS, in Windows 2003. VSS attempts to solve a key problem—the constant expansion of the backup and restore window. Because of today's inexpensive disk space and applications' large appetites for storage, administrators are constantly challenged with data sets that continually grow and disaster-recovery facilities that don't. Administrators have many methods—such as growth management (e.g., archiving, Hierarchical Storage Management—HSM, quotas)—of dealing with this problem, but what they really want is a way to increase backup and (more importantly) restore speeds. If you could increase backup rates from 10GB per hour to 20GB per hour, your backup window would shrink by 50 percent.

VSS addresses one primary concern—that a lot of today's data is online. For example, consider a 24 * 7 file server with thousands of user files. Whenever a typical backup runs, a few files will be open. To complete the backup, you have three choices. First, you can stop the service or session and close the open files. Second, you can skip open files and hope they don't get lost or corrupted before the next backup. But the best solution is to take a snapshot of the data and use the snapshot as the basis for recovery.

VSS provides a framework for using snapshot and cloning technologies with the Windows platform. More specifically, VSS provides services that deliver an infrastructure upon which the OS, applications, and vendors (e.g., Hewlett-Packard—HP—EMC, VERITAS Software, LEGATO Systems) can leverage these technologies.

   Previous  [1]  2  3  Next