Snap/clone technology overview |
 |
By Jerry Cochran
01 Nov 2004 | SearchExchange.com |
 |


|
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.
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).
');
// -->
|
 |
|
 |