Secure snaps are an optional setting for SnapVX targetless snapshots that prevent a user from deleting snapshots accidentally or intentionally and are retained in resource-limited situations in which conventional snaps are placed into a failed state to release resources. The best protection is provided by a combination of conventional snaps for frequent points-in-time for granular recovery options, and less frequent secure snaps for increased protection and resiliency to recover for more critical situations caused by severe application issues and malicious attacks.

Secure snaps are available beginning with the HYPERMAX OS 5977.1125.1125 Q2 2017 Release using Solutions Enabler 8.4, Unisphere 8.4, and REST API 8.4.

Secure snaps allow the user to set a retention period on snapshots. No user can terminate the secure snap during the retention period. Attempts to terminate a secure snap prior to the retention date are rejected. When the retention time is reached the snapshot is automatically terminated.

Users may extend a retention period in situations where a snapshot is needed longer than originally planned. However, reducing a retention period is not allowed. A traditional snapshot may be converted to a secure snap, but a secure snap may not be converted to a traditional snapshot. All SnapVX operations and rules for traditional snapshots regarding restores, linked target operations, and automatic expiration also apply to secure snaps. If a secure snap has any linked targets or restored sessions when the expiration date is reached the snapshot does not terminate until the targets are unlinked or the restored session is terminated.

When implementing secure snaps, a user should determine how many snapshots on an array must be secure. Users should consider using secure snaps only on certain critical volumes, or only on a subset of the snapshots to capture points-in-time that are critical to the business, and for how long the secure snaps should be retained. As always, proper planning and system sizing is crucial, no matter the types or number of snapshots that will exist in an environment.

The CLI format of the retention period is the same as that of the traditional expiration date. The traditional expiration date and secure retention period cannot be used together on a single snapshot.

The following is the Solutions Enabler command structure along with an example of setting a snapshot to secure for one day and 12 hours:

symsnapvx -sg <sg> -name <snapshot_name> establish –secure <-delta | absolute>

symsnapvx -sg prod_sg -name daily_8am_snap establish –secure -delta 1:12

The following figure shows how to create secure snaps with the Unisphere snapshot wizard. A snapshot cannot be set as secure if the standard expiration date has already been set. Likewise, the standard expiration date cannot be set on a snapshot if secure snapshot has already been selected.

Figure 12.    Creating secure snaps in Unisphere 9.0

When a SnapVX snapshot is created, whether secure or traditional, the expiration date/time is stored on the array. Changing the date and/or time on the application server, NTP server, or anywhere else in the environment will not affect existing snapshots. The snapshots will be retained for the required retention period regardless of any changes external to the array.

Moreover, the date/time of PowerMax and VMAX AF arrays cannot be changed from any external interfaces such as Solutions Enabler and Unisphere. Dell Support has tools to modify array time if needed, however, like all support tools, access is secured by RSA Secure Service Credentials which restrict access to an array and further restrict tools according to user level.

Secure snap behavior and use case comparison to traditional snapshots

Secure snaps are intended for use in environments where protecting specific point-in-time images are considered the highest priority and therefore exhibit several behavioral differences compared to traditional snapshots. For example, if the system is reaching Replication Cache or SRP resource limits the user cannot terminate secure snaps to help remediate the situation as can be done with traditional snapshots.

Secure snaps are also unique in the handling of host writes and snapshots when SRP or Replication Cache limits are reached. When Reserved Capacity of an SRP is reached and a host write to a source volume requires a new allocation in the SRP, an existing traditional snapshot is placed into a failed state. However, secure snaps can grow past the Reserved Capacity limit of the SRP. New secure snaps cannot be created once Reserved Capacity is reached.

Preserving the secure snaps takes priority over host writes to those source volumes in the event the entire SRP runs out of available capacity. This is the intent of the feature. For example, if there is an intentional attack or a runaway application on a system that consuming all available capacity, preserving the secure snaps allows the user to restore from the secure snaps once the situation is resolved.

Note: Secure snapshots may only be terminated after they expire or by customer-authorized Dell Support. See the knowledge base article 498316 for more information: https://support.emc.com/kb/498316