Home > Storage > PowerMax and VMAX > Data Protection > Dell PowerMax 2500 and 8500: TimeFinder SnapVX Snapshots and Clones > SnapVX targetless snapshots
SnapVX snapshots are preserved, point-in-time images that protect applications against corruption. SnapVX snapshots are efficient, pointer-based structures that preserve point-in-time views of an application without requiring a target volume. Taking a snapshot of a Storage Group creates a SnapSet consisting of the individual snapshots of the volumes in the Storage Group. The SnapSet is displayed to users as a single snapshot with a name and date based on the SnapSet for ease of management.
Taking a snapshot of a parent Storage Group creates a snapshot with all volumes in the child Storage Groups. The snapshots across the Storage Group are dependent write consistent, and all have the same name and date. Snapshots of a parent Storage Group can be used to restore or link a subset of the child Storage Groups. This functionality can be helpful when a consistent snapshot is created for a whole database, but for recovery purposes, only the child Storage Group with the database files is restored. Storage groups are array-based and do not span arrays.
Snapshots do not initially consume any capacity. Snapshot capacity usage increases as application data of source volumes is updated. The changed data is preserved as snapshot deltas. Snapshot deltas are shared across subsequent snapshots for capacity efficiency and linked targets. Access to shared or unique snapshot data during snapshot restore or link and relink is transparent. Each source volume supports up to 1,024 total sessions, which are the combination of snapshots and clones associated with the source volume. This efficiency provides capacity savings.
Each snapshot has a user-defined name that can be modified at any time. The name has up to 32 characters and can contain letters (not case-sensitive), digits, dashes, and underscores. Versioning is automatically applied when an application has multiple snapshots with the same name. The name assigned to a snapshot is purely for identification purposes and does not affect functionality or data efficiency across snapshots.
Best practice: Use SnapVX snapshots to protect application data. SnapVX linked targets and Clones are used for providing host-accessible copies of data to hosts for other purposes discussed in later sections.
An expiration date known as the time-to-live (TTL) can be applied to each snapshot. Snapshots automatically terminate when the TTL expires unless the snapshot has targets linked or is being used for a restore. Expired, in-use snapshots terminate after the target is unlinked or the restore session is terminated.
TTL values can be specified when the snapshot is created, and can be set, modified, or removed on existing snapshots. The maximum retention time for automatic expiration is 400 days. If no expiration date is set, the snapshot will exist until manually terminated.
TTL values can be set as a specific date (absolute) or a specified number of days or hours (delta) or both. When a date is specified, a delta is calculated from current host time to the specified date. There is no need to synchronize clocks or calculate times between servers and the storage array.
Best practice: Always set an expiration date when creating snapshots. Even when planning to terminate the snapshots manually or by script, setting an expiration date is the safest way to prevent snapshots from being forgotten and consuming system resources.
Versioning is automatically applied to identify multiple snapshots with the same name. Two versioning mechanisms are used: SnapSet ID, and Generation ID.
A SnapSet is a set of consistent snapshots that are taken together. For example, taking a snapshot of a Storage Group that contains 10 volumes results in a SnapSet consisting of 10 consistent snapshots. For ease of management, a single snapshot is shown for the Storage Group with the snapshot name and date, based on the SnapSet.
The SnapSet ID is a system-generated number applied to all snapshots in a SnapSet and can be used to identify and operate on the snapshot of the Storage Group.
The Generation ID of a snapshot is a dynamic value that changes as snapshots are created and terminated. When viewing snapshots, the displayed Generation IDs are relative to the existing snaps at the time. Consistent snapshots across a SnapSet may not have the same Generation ID.
The most recent snapshot on a volume is Generation 0. The oldest snapshot will have the highest generation ID. As new snapshots are taken, the Generation ID increments on existing snapshots of the same snapshot name. Similarly, as more recent snapshots are terminated, the Generation ID of older snapshots decrements.
Best practice: Identify snapshots by SnapSet ID as the value is static and same across the SnapSet. While Generation ID may suffice on a small scale, SnapSet ID is better with higher snapshot counts and frequently scheduled snapshots. As such, Unisphere only displays the SnapSet ID. Avoid trying to correlate the two values as the relationship may change.
Snapshot restores are differential. Source volume pointers are changed to reference the snapshot deltas that were previously preserved. Data that was written to the source after the snapshot was taken is discarded.
Data is immediately available after the restore command completes even while the underlying operation is in progress. Some overhead may be incurred when accessing data that has not yet been restored. The restore process usually completes quickly enough to be transparent to the application.
Best practice: The source volume should not be in use (for example, file systems should be unmounted) before the restore command. Perform a remount after the operation completes to ensure that the host operating system is not viewing cached file system data or keeping locks on data that is being changed at the storage level. The specific host operating system may require a SCSI rescan if volumes were added to the host for the first time, and a reboot should be avoided.
The restore session can be terminated without terminating the snapshot. The snapshot is available for subsequent restores and other uses. Restoring from a snapshot does not affect the point-in-time data of other snapshots.
Best practice: Use snapshot restores to fully restore all application data residing on the volumes in the Storage Group. To perform surgical recovery of specific data (such as some missing files, or a specific application table), use linked target volumes to mount snapshot data and retrieve the required components. Linking a snapshot to target volumes is covered in later sections. Also, consider taking a snapshot of a Storage Group before the restore to preserve the current point-in-time image in case it is needed in the future.
A single snapshot can be terminated if it is not being used for a restore or has linked targets. When snapshots are terminated, snapshot delta storage capacity is freed if not used by other snapshots or clones, and not shared or deduplicated with other volumes. Bulk Terminate will not affect secure snaps, which are covered later.
Bulk Terminate allows termination of many snapshots across a Storage Group with the following options:
The Bulk Terminate options are intended to simplify deletion of multiple snapshots. The operations terminate as many snapshots as possible even if some cannot be terminated. After a Bulk Terminate operation completes, verify that all intended snapshots were successfully terminated.
Besides the Bulk Terminate options, you can use Unisphere to manually select multiple snapshots of a Storage Group and terminate them with a single operation.