Video Screencast Help
Storage & Clustering Community Blog

Storage Foundation Point in Time Copy or Snapshot

Created: 18 Mar 2013 • Updated: 11 Jun 2014
Corradino Milone's picture
+1 1 Vote
Login to vote

 

Point in time copy is a technology that permit to make the copies of a large sets of data a common activity.

Like photographic snapshots capture images of physical action, point in time copy or snapshot are virtual or physical copies of data that capture the state of data set contents at a single instant. Both virtual (copy-on-write) and physical (full-copy) snapshots protect against corruption of data’s content. Additionally, full-copy snapshots can protect against physical destruction. These copies can be used for a backup, a checkpoint to restore the state of an application , data mining, test data and kind of off-host processing. An important peculiarity of these copies is that from the application point of view the copy seems to occur atomically. That means that all the data updates that happens on the original data are applied before or after the point in time copy.

The definition that the Storage Networking Industry Association (SNIA) gives to Point in time Copy is:

Point In Time copy (PIT copy)
A fully usable copy of a defined collection of data that contains an image of the data as it appeared at a single instant in time.
 A PIT 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 (e.g., via database log replay or rollback) 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.Three important classes of point in time copies are split mirror, changed block, and concurrent. Pointer remapping and copy on write are implementation techniques often used for the latter two classes.

The Storage Foundation offers different PIT copy facilities at volume level, file system level and file level [1].

Volume Snapshot [2]

Veritas Volume Manager (VxVM, component of the Storage Foundation suite) can take an image of a volume at a given point in time. This image is called a volume snapshot. Physically a snapshot may be a full (complete bit-for-bit) copy of the data set, or it may contain only those elements of the data set that have been updated since snapshot creation. The latter are sometimes referred to as allocate-on-first-write snapshots, because space for data elements is added to the snapshot image only when the elements are updated (overwritten) for the first time in the original data set. Storage Foundation allocate-on-first-write snapshots are called space-optimized snapshots.

  • Third-mirror break-off snapshots 

A mirror (plex) is used to create the snapshot. The snapshot operation "breaks off" the plex, which becomes the snapshot volume. You can break off an existing plex or add a new plex specifically to serve as the snapshot mirror. The snapshot plex must be on a different disk from the existing plexes in the volume, within the same disk group. The disk must have enough disk space to contain the contents of the existing volume. When you create the snapshot, the plexes are separated into two volumes. The original volume retains its original plex or plexes. The snapshot volume contains the snapshot plex. The original volume continues to take on I/O. The snapshot volume retains the data at the point of time when the snapshot was created, until you choose to perform processing on that volume. You can make multiple snapshots, so you can have multiple copies of the original data. Snapshot volume can be deported from the original system (Disk group split/join) and imported on another host that is dedicated to off-host processing.

  • Space-optimized instant volume snapshots 

Space-optimized snapshots do not contain complete physical images of the original data objects they represent. Space-optimized instant snapshots record changed regions in the original volume to a storage cache. As the original volume is written to, VxVM preserves its data in the cache before the write is committed. As the storage cache typically requires much less storage than the original volume, it is referred to as space-optimized. Space-optimized snapshots consume storage and I/O bandwidth in proportion to how much data on the original volume is updated during the life of the snapshot. Space-optimized snapshots cannot be taken off-host for auxiliary processing.

  • Full-sized instant snapshots 

Full-sized instant snapshots are a variation on the third-mirror volume snapshot model that make a snapshot volume available for I/O access as soon as the snapshot plexes have been created. Practically the snapshot is instantly usable for I/O, like the space-optimize instant volume snapshot, and in background it is aliened to became like a third-mirror break-off snapshots.

  • Linked break-off snapshot [1]

A variant of third-mirror break-off snapshots are linked break-off snapshots, which use a specially prepared snapshot volume linked to the data volume, but set up in a different disk group from the data volume. This makes linked break-off snapshots especially suitable for recurring off-host processing applications as it avoids the disk group split/join administrative step.

Snapshot File System [2]

A snapshot file system is an exact image of a VxFS file system, referred to as the snapped file system, that provides a mechanism for making backups. The snapshot is a consistent view of the file system “snapped" at the point in time the snapshot is made. A snapshot file system is always read-only, it exists only as long as the snapped file system is mounted, and the snapshot file system ceases to exist when unmounted. A snapped file system cannot be unmounted until all of its snapshots are unmounted. Although it is possible to have multiple snapshots of a file system made at different times, it is not possible to make a snapshot of a snapshot.

Storage Checkpoints

A Storage Checkpoint is a persistent image of a file system at a given instance in time. Storage Checkpoints use a copy-on-write technique to reduce I/O overhead by identifying and maintaining only those file system blocks that have changed since a previous Storage Checkpoint was taken. Storage Checkpoints allow write operations to the Storage Checkpoint itself, persist after a system reboot or failure, share the same pool of free space as the file system. Various backup and replication solutions can take advantage of Storage Checkpoints. The ability of Storage Checkpoints to track the file system blocks that have changed since the last Storage Checkpoint facilitates backup and replication applications that only need to retrieve the changed data.

FileSnaps

A FileSnap is an atomic space-optimized copy of a file in the same name space, stored in the same file system. FileSnaps provide an ability to snapshot objects that are smaller in granularity than a file system or a volume. The ability to snapshot parts of a file system name space is required for application-based or user-based management of data stored in a file system. This is useful when a file system is shared by a set of users or applications or the data is classified into different levels of importance in the same file system.

 

A complete guide about the Storage Foundation snapshot facilities can be found in the Yellow Book "Using Local Copy Services", at the following address with other book that provide technical know-how about Symantec technology [3]. 

 

[1] Veritas Storage Foundation and High Availability Solutions Solutions Guide:

 https://sort.symantec.com/public/documents/sfha/6.0/solaris/productguides/html/sfha_solutions/

[2] Using Local Copy Services: 

http://eval.symantec.com/mktginfo/enterprise/yellowbooks/using_local_copy_services_03_2006.en-us.pdf

[3] Symantec Yellow Books: 

http://www.symantec.com/page.jsp?id=yellowbooks