Looking for something else?
The following is tip #16 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from
the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.
Snapshot and cloning technology is not new to the computer industry, but it is relatively new to the Windows platform. This is partially due to the slow adoption rate of technologies like Storage Area Networks (SANs) and Network Attached Storage (NAS) in the Windows space.
Cloning and snapshot technologies provide business continuance volumes (BCVs), thereby providing a much needed capability to the Windows space. BCVs are marketing terminology for snapshots and clones. Simply put, clones and snapshots provide a mechanism for data duplication and point-in-time copies that allows business continuance -- thus, the term BCV. On the surface, clones and snapshots may appear to be the same technology. However, they are quite different in actual technical implementation.
A snapshot is a metadata mapping to volume blocks that represent the "picture" (thus, the word snapshot) of the data at the time the snapshot was created. This means that if you create a snapshot of your Exchange database volume, the snapshot represents the list of the blocks on disk that were used to store your Exchange database (and any other files on the volume) at the time the snapshot was created.
Therefore, once a snapshot has been created for a volume, these original volume blocks must be maintained in order for the snapshot to stay intact; snapshot data cannot be moved to other blocks, although it is possible to add data in new blocks that are not on the snapshot list. This requirement forces changes to blocks on the volume to be copied out (snapshots are also known as copy-on-write snapshots) to another location in the storage pool.
From an Exchange viewpoint, this means that a change to a page in the Exchange database will require copy-out operations of changed blocks if a snapshot has been created for the volume on which Exchange data resides. On a volume for which a snapshot has been created, when a block of data is changed, the block is actually copied out and another block is allocated from free volume pool space. In this manner, the contents of the original subset of volume blocks that represent the snapshot are preserved.
Thus, after snapshot creation, the production data is actually a combination of original unchanged blocks (that are still part of the snapshot) and the changed (copied-out) blocks of data. The snapshot contains the original set of blocks that represent the data view at the time the snapshot was created. From this description, it is obvious that a snapshot is not really a complete redundant copy of the data, but a representation of the data at a point in time. Part of the snapshot is still part of the production data set and part represents out-of-date data (shown in Figure 5.5). Due to the nature of snapshots, creation is relatively quick and simple -- the volume block mapping is simply created and the snapshot exists. Based on the particular characteristics of snapshot technology (it is not a complete redundant copy of the data and is subject to disk failures), snapshots are somewhat less desirable than clones.
Like snapshots, clones are not a recent development. Disk clones come from a foundation of RAID technology -- specifically RAID0+1. A clone is, in actuality, just an additional member of a RAID0+1 mirrorset. Typically, we think of mirrored volumes as only having two members. The Windows Logical Disk Manager (LDM) provides two-way mirroring, as do most hardware RAID controllers. However, some software volume managers and high-end storage controllers allow for N-way mirrors, where N may range from 3 to 32.
For example, if you have a RAID0+1 set with 3 disks mirrored to 3 disks, you have a two-member RAID0+1 set. By adding another 3 disks to the existing RAID0+1 set, you would create a three-member mir¬rorset (a triple mirror). Additional members could be added to the mirror-set as well. By creating multimember mirrorsets and separating members from the set, you gain the ability to create point-in-time clones of the mir¬rored volume. Unlike snapshots, a clone is a complete standalone copy of the data at a particular point in time.
To create a clone, one or more members of the RAID0+1 mirrorset is simply spilt off from the production set. The result is a production mirror-set that supports the application (two-member RAID0+1 array) and one or more clones (each containing a copy of your data) that have been split off from the production data (as shown in Figure 5.6). Clones can then be used in the event of data corruption or loss to recover system data by replacing the production copy with one of the cloned copies. Because clones are a complete redundant copy of the data, they are extremely useful as rapid recovery mechanisms.
Get more "20 tips on protecting and recovering Exchange data in 20 minutes". Return to the main page.
About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).