PowerStore Snpashots

So far, we have covered the following aspects of Dell EMC PowerStore:

High Level Overview, Hardware, AppsON, vVols, File Capabilities, User Interface , Importing external storage

As data becomes increasingly important to organizations of all types, these organizations continually strive to find the safest and most effective ways to protect their data. While many methods of data protection exist, one of the simplest and most-effective methods involves using snapshots. Snapshots allow recovery of data by rolling back to an older point-in-time or copying select data from the snapshot. Snapshots continue to be an essential data-protection mechanism that is used across a wide variety of industries and use cases.
Snapshots can preserve the most important mission-critical production data, sometimes with other dataprotection technologies.
Dell EMC™ PowerStore™ provides a simple but powerful approach to local data protection using snapshots.

PowerStore uses the same snapshot technology across all the resources within the system, including volumes, volume groups, file systems, virtual machines, and thin clones. Snapshots use thin, redirect-on-write technology to ensure that system space is used optimally and reduces the management burden by never requiring administrators to designate protection space. Snapshots can be created manually through PowerStore Manager, PowerStore CLI, REST API, or automatically using protection policies. Protection policies can be created and assigned to quickly create local and remote protection on supported resources.
A thin clone is a read/write copy of a volume, volume group, or file system. Thin clones use the same underlying pointer-based technology that snapshots use to create multiple copies of storage resources. Thin clones support many data services, which engineers and developers can leverage in their environments.
When users create a thin clone, it acts as a regular resource and is listed with the other resources of the system. Like snapshots, users can create, manage, and destroy thin clones through PowerStore Manager, PowerStore CLI, and REST API.

Snapshots are the local data protection solution within a PowerStore system. They provide a method of recovery for data that has been corrupted or accidentally deleted. Snapshots are pointer-based objects that provide point-in-time copies of data that is stored in volumes, volume groups, file systems, thin clones, or virtual machines. As snapshots are not full copies of the original data, they should not be relied upon as a backup or as the disaster recovery solution. Snapshots also consume overall system storage capacity to preserve the point-in-time. Ensure that the appliance has enough capacity to accommodate snapshots.
Snapshots can be created either manually or automatically within a PowerStore system and are considered write-order/crash-consistent. A write-order/crash-consistent snapshot is not considered application consistent since the snapshot may not be a full representation of the application dataset at that point-in-time. Typically, a host/client caches data with the intention to write it to the storage resource. Cached data is not available within the storage when a snapshot is taken. To create application-consistent snapshots, use Dell EMC AppSync™ where supported. AppSync ensures all incoming I/O for a given application is quiesced and flushed before a snapshot is taken.
While the following sections outline the creation and management of snapshots in PowerStore Manager, snapshots can also be created and managed using the PowerStore CLI and REST API. Whether administrators take manual snapshots through PowerStore Manager, use the customizable snapshot rules, or create advanced data protection scripts, they can fully manage their storage environments using whichever method that they prefer. This ability leads to a powerful, flexible foundation for managing data protection regardless of the complexity of the use case or environment.

Snapshots overview

Snapshots are the local data protection solution within a PowerStore system. They provide a method of recovery for data that has been corrupted or accidentally deleted. Snapshots are pointer-based objects that provide point-in-time copies of data that is stored in volumes, volume groups, file systems, thin clones, or virtual machines. As snapshots are not full copies of the original data, they should not be relied upon as a backup or as the disaster recovery solution. Snapshots also consume overall system storage capacity to preserve the point-in-time. Ensure that the appliance has enough capacity to accommodate snapshots. Snapshots can be created either manually or automatically within a PowerStore system and are considered write-order/crash-consistent. A write-order/crash-consistent snapshot is not considered application consistent since the snapshot may not be a full representation of the application dataset at that point-in-time. Typically, a host/client caches data with the intention to write it to the storage resource. Cached data is not available within the storage when a snapshot is taken. To create application-consistent snapshots, use Dell EMC AppSync™ where supported. AppSync ensures all incoming I/O for a given application is quiesced and flushed before a snapshot is taken.
While the following sections outline the creation and management of snapshots in PowerStore Manager, snapshots can also be created and managed using the PowerStore CLI and REST API. Whether administrators take manual snapshots through PowerStore Manager, use the customizable snapshot rules, or create advanced data protection scripts, they can fully manage their storage environments using whichever method that they prefer. This ability leads to a powerful, flexible foundation for managing data protection regardless of the complexity of the use case or environment.

Redirect-on-write technology

In this example a storage resource contains four blocks of data: A, B, C, and D. A snapshot is taken of the storage resource to preserve this point-in-time, and points to blocks A, B, C, and D. When the host/client modifies blocks B, A, then D, the data is written to new locations on the system. The pointers for the storage resource are then updated to reflect the new locations for B’, A’, and D’. This example assumes that no data reduction savings are achieved. For more information about data reduction within PowerStore, view the document Dell EMC PowerStore: Data Efficiencies on Dell.com/StorageResources.

Snapshot operations
The following operations are supported on snapshots for all storage resource types unless otherwise noted.
These operations can be completed using PowerStore Manager, PowerStore CLI, or REST API. Usually, the snapshot operations below for volumes, volume groups, file systems, thin clones, and virtual machines are the same. Differences in behavior are explained.

Create
When a snapshot is created, the snapshot contains the state of the storage resource and all files and data within it at that point-in-time. A snapshot is essentially a picture of the resource at that moment in time. After creation, the space that is consumed by the snapshot is virtually zero, since pointer-based technology is used and all data within the snapshot is shared with the parent resource. The amount of data that is uniquely owned by the snapshot increases over time as overwrites to the parent resource occur as previously shown in
screenshot below. In that example, after changes to the parent storage resource were made, blocks A, B, and D are only owned by the snapshot.
Users may manually create snapshots of a storage resource at any time or have them created by the system on a user-defined schedule. To have snapshots created automatically, a user must create and assign a protection policy containing a snapshot rule to a resource. Protection policies and snapshot rules are further explained in this post. The following outlines the process to manually create snapshots on the various resources within a PowerStore system. To create a snapshot on a resource within PowerStore Manager, go to the properties window of the resource, click the Protection tab, click the Snapshots tab, and click Take Snapshot. Figure 2 shows an example of the location of the Take Snapshot button, which is used to create a manual snapshot. This process is the same for all storage resource types, whether the resource is a volume, volume group, file system, thin clone, or virtual machine within PowerStore. In this example, the properties window for a volume is displayed.

Modify
The Modify option is used to update several attributes of an existing snapshot. This can be completed by going to the properties page of a resource within PowerStore Manager, selecting the Protection tab, selecting a snapshot, and clicking Modify. The specific attributes that can be edited are resource-dependent and are further detailed below. For virtual machine snapshots, edits can only be made from vCenter. For volumes, volume groups, and their thin clones, users can view and edit the details of a snapshot by selecting a specific snapshot on the Protection tab within the properties window of the parent resource and clicking Modify. This opens the Details of Snapshot page. An example of the Details of Snapshot page for a volume group snapshot is shown in Figure 6. The user can choose to update the snapshot Name,
Description, and Local Retention Policy. For the Local Retention Policy, the user has the option of selecting No Automatic Deletion or setting a Retain until date and time. In certain situations, changing a snapshot to no automatic deletion may be required, preserving the snapshot until it is determined that it is no longer needed. For volumes and thin clones of volumes and volume groups, the same information can be changed.

Delete
A user can select one or more snapshots of a resource and delete them on demand. From PowerStore Manager, if a single snapshot is chosen within the Protection tab in the properties of a resource and Delete is selected, a confirmation window appears listing the snapshot name and if the user wants to delete thesnapshot. When multiple snapshots are selected, the confirmation window displays a full list of all selected
snapshots when the show more option is used. If the snapshot is of a virtual machine, the snapshot is also removed from vSphere. Deleting a snapshot within PowerStore may return free space back to the appliance. If the snapshot was recently created, the snapshot has pointers to most, if not all, data contained within the parent resource. Also, as PowerStore uses deduplication and compression mechanisms to reduce the amount of data stored within the system, a snapshot may not only have blocks in common with the parent resource, but other resources within the system. Blocks of data only unique to a given snapshot are deleted and space is returned to the system for use by other resources.

Refresh
Volumes and volume groups
The refresh operation has different meanings depending on the resource type. For volumes and their thin clones, the refresh operation replaces the contents of an object with the data of another resource within the same family. For volume groups and volume group thin clones with write-order consistency enabled, the
contents for all members of the group are replaced. When write-order consistency is disabled, individual volumes within a volume group can be refreshed. After a refresh operation is started, the process quickly completes since only pointer updates for the resource are changed. The refresh operation differs from arestore operation, which returns the object to a previous point-in-time copy of itself. A storage resource family consists of the parent storage resource, which is the original resource, any thin clones, and snapshots in the tree. An example is shown in the screenshot below.

Restore
A restore operation reverts a parent resource dataset to a previous point-in-time when a snapshot was taken.
Only snapshots directly taken of the resource can be used as the source for the restore operation. When a restore operation is started, pointer updates occur, and the entire resource dataset is reverted to the previous point-in-time contained within the snapshot. Restore is supported on volumes, volume groups, file systems, and any thin clones of these resources. The restore operation is not supported on virtual machines, but users can use the Revert option in vCenter. If you restore a volume group or volume group thin clone, all member volumes are restored to the point-in-time associated with the source snapshot. More information about volume groups can be found in the section Snapshot interoperability. As mentioned, a restore operation reverts the entire resource back to a previous point-in-time copy of itself. If only a select amount of data must be recovered from a volume or volume group snapshot, accessing a thin clone created using the snapshot in question avoids losing any data that is updated after the snapshot was created. If the resource is a file system or file system thin clone, accessing the protocol (read-only) snapshot through an SMB share or NFS export also avoids the Restore operation when only a subset of data is needed. Accessing file system and file system thin clone snapshots is discussed in detail in the section Snapshot access.
Volume shrink is not supported on PowerStore. Restoring a volume, volume group, or thin clone from a snapshot does not reduce the size of the resource even if the snapshot was taken when the resource was the previous size. Instead, the resource size remains at the current size, but with the original dataset restored. For instance, if the snapshot was taken of the parent volume when it was 500 GBs, and it is now 750 GBs, the operation restores the data to the 750 GB volume. For file systems and thin clones, this behavior is different since file system shrink is supported. The size of the object being restored changes based on the size of the resource when the snapshot was taken. For instance, if the snapshot was taken of the parent file system when it was 100 GBs, and it is now 200 GBs, the restore operation updates the size of the resource to be 100 GBs and the original data is restored.

Volume groups
Snapshots are fully supported with volume groups on a PowerStore system. A protection policy containing a snapshot rule can be assigned to the volume group to take snapshots at a defined interval. Snapshots can also be taken manually on the volume group or on individual volumes within the volume group at any time. This task can be done from the Snapshots tab within the Protection tab of the volume group or member volume.
Volumes can also be added or removed from a volume group without affecting data protection on the group. When a volume is removed from a volume group, no snapshots on the group are deleted or otherwise changed. If replication is configured, it continues and any changes to the group is propagated to the destination during the next sync. If the volume group has a protection policy that is assigned to it and a volume is removed, the policy is automatically assigned to the volume that is removed from the group to continue data protection. Replication on the volume that is being removed from the volume group will continue once a sync occurs on the volume group it was removed from. When attempting the restore or refresh operations on a snapshot of a volume group, ensure that the number of volumes that were in the group when the snapshot was taken match the number of volumes in the volume group that is being restored or refreshed. For instance, if the snapshot was taken when the group had five members, it cannot be used for a restore if the group does not currently contain the five original members. To
access this data, you can create a thin clone from the snapshot. To view the number of members of the group when the snapshot was taken, reference the Volume Members column on the snapshot tab. The write-order consistency setting is a property of the volume group. This setting is enabled by default but can be changed at the creation of the volume group or later. The write-order consistency setting controls whether a snapshot is created at a consistent time across all members of the group. If enabled, the system takes a snapshot at the exact same time across all objects to keep the point-in-time image consistent for the entire group. If disabled, there is a chance that the snapshots on individual volumes within volume group are taken at slightly different times with possibly newly written data. When the snapshot is taken, the write-order
consistency setting is marked as a property of the snapshot, and affects what operations can be done on the snapshot. A column in the snapshot list for volume groups exists to view the write-order consistent property for each snapshot.
When write-order consistency is Yes for a snapshot, the restore and refresh operations have different capabilities than when it is No. When enabled on the snapshot, the restore and refresh operations affect the entire volume group, regardless of the current setting on the volume group. For instance, if Restore is used, all members of the group are restored from the snapshot image. This behavior is the same for the refresh operation. If write-order consistency is No for the snapshot, the restore and refresh operations can be issued to individual volumes within a volume group. The write-order consistency setting also affects the ability to assign a protection policy to a volume group and its members. When write-order consistency is enabled on the group, users can only assign a protection policy to the volume group itself. Assigning a protection policy to an individual member is not supported. When writeorder consistency is disabled on the volume group, users can choose to assign a policy to the group, or its individual members, but not both. This action provides flexibility for protecting the various members of the group with different protection policies.
When a volume group is deleted, the user can delete the volume group and retain its members or delete the group along with its members. When only the volume group is deleted, all snapshots taken of the group are also deleted. Any snapshots that are taken of the individual volumes remain. In either case, any thin clones that are created of the volume group or from a snapshot of the volume group also remain unaffected.

A protection policy is a simple, named container of protection rules.

Protection policies automatically manage snapshots or replication operations based on the included rules.

You create policies for your implementation and apply a specific policy to a storage resource based on the business need or criticality of the data.

In the end, what makes a protection policy are the rules that it contains.

Each protection policy can include up to four snapshot rules, and no more than one replication rule.

You apply a protection policy to a storage resource. For any one storage resource, you can apply only one protection policy.

Storage resources include:

You can re-use the same protection policy on many storage resources. This avoids the need to create specific snapshot and/or replication rules for each storage resource.

The ability to re-use a protection policy provides:

Efficiency: Create once and use everywhere.
Consistency: Use same policy for all objects.
Simplicity: Single point of management.

A protection policy must contain at least one rule. You can create rules and then add them to a policy, or you can create the rules at the same time that you create the policy.

This example shows creating a rule before a policy.

To create a snapshot rule:

Under Protection, select Protection Policies.
Select Snapshot Rules.
Click Create.
In the Create Snapshot Rule slideout, specify the details for the new rule.
- Rule Name
- Days
- Frequency/Start Time
- Retention
- File Snapshot Access Type
Click Create.

The new Snapshot Rule appears in the list:

To create a policy and add a rule:

Under Protection, select Protection Policies.
Click Create.
In the Create Protection Policy slideout, enter a Policy Name.
Enter a Description for the policy.
Check the box to select at least one Snapshot Rule.
Click Create.

To assign a protection policy to a volume:

Go to Storage > Volumes.
From the list of volumes , check the box next to the storage
resource to be protected.
From the More Actions menu, select Assign Protection Policy.
In the Assign Protection Policy slideout, check the box next to the policy you wish to apply.
Click Apply.

Thin clone overview
A thin clone is a read/write copy of a volume, volume group, file system, or a snapshot of these resource types. Thin clones are essentially thin copies of the object it was created from. As with snapshots, thin clones are thin, pointer-based objects which use redirect-on-write technology that provides immediate access to the data contained in the source of the thin clone. Thin clones are not full copies of the original source and should not be used for disaster recovery scenarios. The screenshot below, shows an example of a thin clone that is created from a supported resource. When initially created, the thin clone shares all blocks with the resource it was created from. Due to redirect-on-write technology, as new writes to the original resource or the thin clone are made, new space is consumed, and original data remains until it is no longer in use.

Thin clones also support local and remote data protection. For a thin clone to be protected, manual snapshots can be taken at any time, or a protection policy can be assigned to it. The screenshot below, shows an example of a thin
clone with a protection policy assigned. It contains a snapshot rule and an RPO-based replication rule. The resource is also mapped to a host for access.

Thin clones within PowerStore are treated as an autonomous resource, as if they were a separate volume, volume group, or file system. When created, they are listed on the main resource page, such as the Volumes or File Systems page. The properties window for a thin clone contains the same information as other resources, and the method to delete a thin clone is also the same. As an added benefit, parent resources can be deleted without deleting their thin clones. This action does not impact the thin clone or any snapshots the thin clone may have.
Use thin clones to create and manage space-efficient copies of production environments, which is beneficial for the following types of activities:
• Development and test environments: Thin clones allow test and development personnel to work with real workloads and use all data services that are associated with production storage resources without interfering with production. They also allow development personnel to promote a test thin clone to production.
• Parallel processing: Parallel processing applications that span multiple servers can use multiple thin clones of a single production data set to achieve results more quickly.
• Online backup: Use thin clones to maintain hot backup copies of production systems. If there is corruption in the production data set, the read/write workload can be immediately resumed using the thin clones.
• System deployment: Use thin clones to build and deploy templates for identical or near-identical environments. For example, create a test template that is thin cloned as needed for predictable testing.

Below, you can see a demo, showing how to create a protection policy with snapshots