Snap/clone technology overview
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
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by Exchange professionals today working with Exchange, Outlook and other related technologies.
Margie Semilof, Editorial Director
Premium Access
Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy
Dig Deeper
-
People who read this also read...
-
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.
Snapshots
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.
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).
