Using different types of storage snapshot technologies for data protection

By Marc Staimer 22 Dec 2009 | SearchDataCenter.in

Digg This!     StumbleUpon     Del.icio.us

There are six general types of snapshot technologies (see table below):

• Copy-on-write
• Redirect-on-write
• Clone or split-mirror
• Copy-on-write (COW) with background copy
• Incremental
• Continuous data protection (CDP)

	Snapshot technology
	Copy-on-write	Redirect-on-write	Clone/split mirror	COW w/ background copy	Incremental	CDP
Snapshot is tightly coupled to original data	Yes	Yes	No	Yes, until background copy finishes	Depends on how original snapshot is generated	No
Space efficient	Yes	Yes	No	No	No	Yes, versus multiple point-in-time snapshots
Original data system IO and CPU resource overhead	High	Medium	Low	Low	Low	Low
Write overhead on orig. data copy	High	None	None	High	High	High
Protects against logical data errors by rolling back to orig. copy	Yes	Yes	Yes	Yes	Yes	Yes
Protects against physical media failures of orig. copy	No	No	Yes	After background copy completes	Depends on underlying snapshot tech.	Yes

Copy-on-write snapshot

Copy-on-write requires storage capacity to be provisioned for snapshots, and then a snapshot of a volume has to be initiated using the reserved capacity. The copy-on-write snapshot stores only the metadata about where the original data is located, but doesn't copy the actual data at the initial creation. This makes snapshot creation virtually instantaneous, with little impact on the system taking the snapshot.

The snapshot then tracks the original volume paying attention to changed blocks as writes are performed. As the blocks change, the original data is copied into the reserved storage capacity set aside for the snapshot prior to the original data being overwritten. The original data blocks snapped are copied just once at the first write request. This process ensures snapshot data is consistent with the exact time the snapshot was taken, and it's why the process is called "copy-on-write."

Read requests to unchanged data are directed to the original volume. Read requests to changed data are directed to the copied blocks in the snapshot. Each snapshot contains metadata describing the data blocks that have changed since the snapshot was first created.

The major advantage of copy-on-write is that it's incredibly space efficient because the reserved snapshot storage only has to be large enough to capture the data that's changed. But the well-known downside to copy-on-write snapshot is that it will reduce performance on the original volume. That's because write requests to the original volume must wait to complete until the original data is "copied out" to the snapshot. One key aspect of copy-on-write is that each snapshot requires a valid original copy of the data.

Redirect-on-write (ROW) snapshot

Redirect-on-write is comparable to copy-on-write, but it eliminates the double write performance penalty. ROW also provides storage space-efficient snapshots like copy-on-write. What allows ROW to eliminate the write performance penalty is that the new writes to the original volume are redirected to the storage provisioned for snapshots. ROW redirection of new writes reduces the number of writes from two to one. So instead of writing one copy of the original data to the storage space plus a copy of the changed data required with COW, ROW writes only the changed data.

With redirect-on-write, the original copy contains the point-in-time snapshot data, and it's the changed data that ends up residing on the snapshot storage. There's some complexity when a snapshot is deleted. The deleted snapshot's data must be copied and made consistent back on the original volume. The complexity goes up exponentially as more snapshots are created, which complicates original data access, snapshot data and original volume data tracking, and snapshot deletion data reconciliation. Serious problems can occur when the original data set (upon which the snapshot is dependent) becomes fragmented.

Clone or split-mirror snapshot

A clone or split-mirror snapshot creates an identical copy of the data. The clone or split-mirror can be of a storage volume, file system or a logical unit number (LUN). The good thing about clones is that they're highly available. The bad thing is that because all of the data has to be copied, it can't be done instantaneously. A clone can be made instantaneously available by splitting a pre-existing synchronous volume mirror into two. However, when a split-mirror is used as a clone, the original volume has lost a synchronized mirror.

A very significant downside to this snapshot methodology is that each snapshot requires as much storage capacity as the original data. This can be expensive, especially if more than one snapshot clone is required to be kept live at any given time. One other downside is the impact to system performance because of the overhead of writing synchronously to the mirror copy.

Copy-on-write with background copy snapshot

Copy-on-write with background copy takes the COW instantaneous snapshot data and uses a background process to copy that data from its original location to the snapshot storage location. This creates a clone or mirror of the original data.

Copy-on-write with background copy attempts to take the best aspects of copy-on-write while minimizing its downsides. It's often described as a hybrid between COW and cloning.

Incremental snapshot

An incremental snapshot tracks changes made to the source data and snapshot data when the snapshot is generated. When an incremental snapshot is generated, the original snapshot data is updated or refreshed. There's a time stamp on the original snapshot data and on each subsequent incremental snapshot. The time stamp provides the capability to roll back to any point-in-time snapshot. Incremental snapshots allow you to get faster snapshots after the first one, and you use only nominally more storage space than the original data. This enables more frequent snapshots and longer retention of snapshots.

The downside to incremental snapshots is that they're dependent on the underlying baseline technology used in the first snapshot (copy-on-write, redirect-on-write, clone/split-mirror or copy-on-write with background copy). If cloned, the first snapshot will take a while; if COW, there will be a performance penalty on writes to the original data, etc.

Continuous data protection

Continuous data protection was developed to provide zero data loss recovery point objectives (RPOs) and instantaneous recovery time objectives (RTOs). It's similar to synchronous data mirroring except that it eliminates the rolling disaster (a problem in the primary data is automatically a problem with the mirrored data long before human intervention can stop it) and protects against human errors, malware, accidental deletions and data corruption.

Continuous data protection is like incremental snapshots on steroids. It captures and copies any changes to the original data whenever they occur and time stamps them. It essentially creates an incremental snapshot for every moment in time, providing very fine-grain recoveries. Some CDP implementations are both time and event based (such as an application upgrade). A good way to think of CDP is as a journal of complete storage snapshots.

Continuous data protection is an excellent form of data protection for email, databases and applications that are based on databases. The ability to roll back to any point-in-time makes recoveries simple and fast. FalconStor's IPStor is an example of a storage system and/or virtualization appliance that provides CDP.

With more and more data to protect and often less time to do it, snapshots will play a bigger role in data protection and daily storage operations. Although the differences among snapshot technologies may seem subtle, how they operate in your environment could have a significant effect on the level of protection provided and how quickly recoveries can occur.

This article originally appeared in Storage magazine.

About the author: Marc Staimer is the founder, senior analyst, and CDS of Dragon Slayer Consulting in Beaverton, OR. The consulting practice of 11 years has focused in the areas of strategic planning, product development, and market development. With over 28 years of marketing, sales and business experience in infrastructure, storage, server, software, and virtualization, he's considered one of the industry's leading experts. Marc can be reached at marcstaimer@comcast.net.

Tags: Data backup and disaster recovery,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Data backup and disaster recovery Disaster recovery, power and cooling secrets from Airtel data centers How to determine the appropriate failover disaster recovery site: hot, cold or warm Virtual tape library tweaks to reduce backup windows Disaster recovery checklist: What you need in your DR budget Disaster recovery boosts customer service ops at Punjab National Bank Using information lifecycle management for mainframe disaster recovery Tape library powers business continuity for Globus' retail operations Disaster recovery streamlines business at Jindal Steel Achieving cost-effective disaster recovery testing and planning: Nine areas where you can cut costs Syntel's disaster recovery formula for customer-centric operations

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary