1

Review of Snapshots(Point-in-Time Copy)

Technology

Alex Shraer

22

Bibliography• Point-in-Time Copy: Yesterday, Today and Tomorrow

A. Azagury, M. Factor, J. Satran, W. MickaProceedings of the 10th Goddard Conference on Mass Storage Systems and Technologies/19th IEEE Symposium on Mass Storage Systems 2002

• EMC TimeFinder Family – Data Sheet: http://www.emc.com/collateral/software/data-sheet/1700-timefinder.pdf– White Paper: http://www.emc.com/collateral/software/white-papers/h1618-ensuring-data.pdf

• Understanding and exploiting snapshot technology for data protection

Neeta Garimella, TSM Client Developer, Tivoli - Software Group, IBM

3

Definition: Point-in-Time Copy“A fully usable copy of a defined collection of data that

contains an image of the data as it appeared at a single point-in-time. The copy is considered to have logically occurred at that point-in-time, but implementations may perform part or all of the copy at other times […] as long as the result is a consistent copy of the data as it appeared at that point-in-time. Implementations may restrict point-in-time copies to be read-only or may permit subsequent writes to the copy.”

The Storage Networking Industry Association (SNIA)

4

Why Point-in-Time Copies?• A full backup of a large data set may take a long time to complete

– Meanwhile, in a multi-user/multi-tasking system there might be writes to the area being backed up. This can compromise consistency

– Suppose a user moves a file from a directory that wasn’t backed up yet into a directory that was already backed up. This file will be completely missing from the backup

– What can be done to preserve consistency of the data?

• Stop all updates until backup is complete (e.g., locking)– Might be OK for desktops, or small systems where downtime is acceptable– High-availability 24/7 systems, however, cannot bear service stoppages

• Make a snapshot/point-in-time copy of the volume– A read-only copy of the data set frozen at a point in time– Back up the snapshot– Meanwhile, users can update the source volume

5

Why Point-in-Time Copies?• Non-disruptive backup

– Probably the most common reason• Checkpointing

– Safeguard against failures• Data mining

– Scan a consistent copy of the data without impacting production application

• Testing– Need to test application, but

not on the valuable production data– e.g., Y2K

• Virtualization, sandboxing– Read-write snapshots– Example: VMware snapshots

• What if configuration change / new service pack installation goes wrong?• Create a duplicate of virtual machine including disk, configuration and BIOS• Can always go back in time to where you started!

6

Classes of Implementations

• Split mirror

• Changed block– Copy on write– Redirect on write

• Concurrent

• Continuous Data Protection

7

Split Mirror• A mirror of the data is constructed

prior to the point-in-time copy

• The point-in-time copy is made by “splitting” the mirror

• In some implementations, it is possible to Resynchronize split mirrored copies back with the standard volume

8

Split Mirror Characteristics• Advantages

– Point-in-time copy available instantaneously– Full physical copy provides additional protection

• Disadvantages– Requires advanced planning– Space for copy needs to be pre-allocated– Performance penalty of mirroring– When copy has split, source has one less mirror

9

EMC Timefinder/Mirror: A Split Mirror Implementation• Mirrored images called Business Continuance Volumes (BCVs)

– Up to 16 BCVs per production volume (the standard device)– BCVs can themselves be RAID protected

• BCVs can be split and accessed independently

• Supported operations:– Establish – creates an empty BCV– Isynch – synchronize a BCV with the standard device– Split – splits the BCV from the standard device and makes

it available for use • The content of the BCV volume is a point-in-time copy of the standard device

– Re-establish – re-establishes the link between the standard device and the BCV• The BCV is updated with updates made to the standard device after the split• Updates made to the BCV after the split are discarded

– Restore – Copies the contents of the BCV back to the standard device• Implementations:

• Hitachi’s ShadowImage, EMC Symmterix and AIX Logical Volume Manager • Any mirroring RAID system can be used to create a clone by splitting a mirror

10

Changed Block• Based on the copy-on-write technique

– Before a write is allowed to a block, copy-on-write moves the original data block to the snapshot storage (done only for first write)

– Requires setting up a pointer-table to keep track of modified records– Read requests to the snapshot volume of the unchanged data blocks are

redirected to the original volume

Highly space efficient Availability of the copy depends on the availability of the source Access to source volume might be slightly delayed because of the

copy-on-write

11

Changed Block Implementations• Example: EMC TimeFinder/Snap

– Does not actually create a full copy of the source data

– If the source fails, cannot use the copy to restore it

– Typically requires less than 30% of the source capacity to support the image. But this depends on data change rate and duration of the snap session

– Useful if you need fast, temporary parallel access to production data– Allows to make continues snapshots with minimal resource planning

• Other implementations: – StorageTek’s Shared Virtual Array– Linux® Logical Volume Manager– IBM’s RAMAC Virtual Array (RVA), IBM FlashCopy® (NOCOPY), AIX® JFS2

snapshot, IBM TotalStorage® SAN File System snapshot, IBM General Parallel FIle System snapshot, and IBM Tivoli Storage Manager Logical Volume Snapshot Agent (LVSA)

12

Variation: Redirect-on-write• Copy-on-write requires writing twice

1. old data copied to new volume2. new data written to original volume

• Redirect-on-write: new writes to the original volume are redirected to the new volume

only one write The original volume contains the snapshot, and the changed data reside on the

snapshot storage. When a snapshot is deleted, the data from the snapshot storage must be reconciled back into the original volume.

As multiple snapshots are created, access to the original data, tracking of the data in snapshots and original volume, and reconciliation upon snapshot deletion is further complicated .

The snapshot relies on the original copy of the data and the original data set can quickly become fragmented.

• Implementations: IBM N series, NetApp Filer

13

Concurrent Point-in-Time Copy• copy-on-write with background copy• Similar to “changed block”

– However, physically copies the data (in the background)

• Example: EMC Timefinder/Clone– Clone copy - no mirroring is employed– BCV is immediately available– Result is a separate BCV volume, but only after copying has completed,

unlike in Mirroring, where it is separately available immediately– Activate - Background copy starts, and data is copied before modified in

the standard device– Precopy – start the background copy ahead of activation time

• Before Activate is issued, data is updated in both source and copy

• Another implementation: IBM FlashCopy

14

IBM’s ESS FlashCopy• Concurrent point-in-time copy implementation• Background copy of the source to the target (Optional)• Read/write of copy possible immediately after activation• Target size equal to source size is required• When run on zSeries, partial copy of the volume is allowed and

managed by the host software. – Useful if, for example, the volume is sparse– However, the implementation still requires

a full allocation of space

15

IBM’s ESS FlashCopy – Cont.• When point-in-time copy is invoked, there is usually a time

interval where applications are not allowed to access volumes– Establish relationship between source and target– Allocate data structures needed for copy-on-write– Security verifications, reserve space for data integrity purposes

• This period of time must be minimized

• Impact on application response time – 256 FlashCopy source-target volume pairs– Less than 3% impact on I/O rate without background copy– Less than 7% with background copy

• As copy of some pairs completes, response time goes down• Overhead of background copy is negligible with 32 source-target pairs

zSeries software

FlashCopy software

16

Continuous Data Protection (CDP)• Also called continuous backup• CDP creates a snapshot for every instance in time where data modification

occurs– Each change made to the data is automatically captured to a separate storage

location – CDP effectively creates an electronic journal of complete storage snapshots– Unlike other methods which create a single point-in-time copy of the data

• Can provide fine restore granularities, from any point to a consistent image of application data

• What is continuous? – every write (the SNIA definition) vs. every few seconds– How far back can we restore?

• Implementations: – BackBone (CDP for Linux)– Zmanda (CDP for MySQL)– Atempo, SonicWALL

17

Additional Parameters to Consider• Some implementations put additional

limitations on the copy, such as: – Read-only– Only sequential reads– etc.

• In the TimeFinder Family: read/write of copy allowed immediately after “Split” or ”Activate”

• Another parameter - resilience to failures of the copy– Possibility to use RAID 5 in TimeFinder

18

File Level Implementations• Block level copy - reduces load on the file server and on the

storage network• File level allows granularity control• Many UNIX-like file systems have leveraged their inode pointer-

based data structures to for efficient snapshot capabilities• Snapshot points initially to same data blocks as the source• Then, copy-on-write is used

– Snapshots are usually read-only– Main purpose – backup with minimal disruption of the production file

system, using the created snapshot– Example: Andrew File System– Commercial example: Network Appliance

• Possible drawback– Both data and meta-data are read-only. A user that was revoked access to

the production file system can still access the snapshots

19

Future Trends• Improving Today’s Point-in-time Copy

– Reducing impact on application even further

• Using logical structure of data to physical layer copy– Perhaps using object based storage

• In Object Based Storage the storage subsystem has complete control over device block location information and internal object structure– files, database tables, etc. are also storage objects– Point-in-time copy can be made with minimal space and time overhead

and encompass any set of objects (not necessarily a volume or a large portion of a volume)