Cloud volumes and snapshots

A cloud volume is any volume that is enabled for transparent cloud tiering. After transparent cloud tiering is enabled on a volume, point-in-time copies, or snapshots, can be created and copied to cloud storage that is provided by a cloud service provider. These snapshots can be restored to the system for disaster recovery purposes. Before you create cloud volumes, a valid connection to a supported cloud service provider must be configured.

With transparent cloud tiering, the system supports connections to cloud service providers and the creation of cloud snapshots of any volume or volume group on the system. Cloud snapshots are point-in-time copies of volumes that are created and transferred to cloud storage that is managed by a cloud service provider. A cloud account defines the connection between the system and a supported cloud service provider and must be configured before data can be transferred to or restored from the cloud storage. After a cloud account is configured with the cloud service provider, you determine which volumes you want to create cloud snapshots of and enable transparent cloud tiering on those volumes.

In the management GUI, volumes that do not have restrictions are enabled for cloud snapshots when a snapshot is created for that volume. If you are using the command-line interface, you must enable snapshots on the volume before you can create a snapshot of the volume.

A volume cannot be enabled for cloud snapshots if the volume is used in any of the following capacities:

The volume is a VMware vSphere Virtual Volumes.
A volume has a copy in a different storage pool.
A volume is being migrated between different storage pools.
A volume cannot be enabled for cloud snapshots if the cloud storage is set to import mode.
A volume cannot be enabled for cloud snapshots if the maximum number of cloud volumes already exists. The maximum number of cloud volumes on the system is 1024.
Note: If the system exceeds this limit, you can disable cloud snapshots on an existing cloud volume and delete its associated snapshots from the cloud storage to accommodate snapshots on new cloud volumes.
The volume is associated with user-owned legacy FlashCopy® mappings.
Note: Cloud snapshots are supported with the system's new FlashCopy management model based on snapshot function. For more information about snapshot function, see related information section.

After the volume is enabled for the function, cloud snapshots of those volumes can be created and stored on cloud storage. Multiple snapshots can be created at different times and each version is timestamped and stored in the cloud storage. Each snapshot version on the cloud storage represents the data at a specific point in time, so different versions can be restored if necessary. The system supports both snapshots of local system data and also data on different systems. Some of these cloud snapshots can have corresponding cloud volumes on the local system, but other snapshots might not. You can restore data from these different snapshots of the cloud volume if necessary. You can use the management GUI or the command-line interface to view any volumes that have snapshots on cloud storage.

The system supports two types of cloud snapshots:

Full snapshots: When the cloud snapshot is created for the first time for a volume, all data is copied to the cloud storage. Any subsequent cloud snapshots of the volume include only the changed data from the initial snapshot. Each snapshot version of the volume is timestamped and stored on the cloud storage. Therefore, full plus incremental snapshots ensure that all data is copied to the cloud storage and is available if a restore operation is necessary. If the volume contains a large amount of data, full snapshots can be time-consuming.
Incremental snapshots: The version contains changed data from the last time the cloud snapshot was created for a selected volume. Incremental-only snapshots are quicker to complete than a full snapshot.

Individual volumes can be added to a single volume group for creating snapshots for all the volumes in that group. If volumes have similar content or are used by a specific host or application, they can be added to volume group to simplify snapshot operations. Separate snapshots are started for each volume in the group and the group must be created before the snapshots are created. Volume groups can be configured by using the mkvolumegroup command. The management GUI lists all cloud volumes and specifies the name of the volume group in which the volumes belong.

If you want to limit access of users to specific volume groups that are used in creating cloud snapshots, you can assign these volume groups to an ownership group. An ownership group defines a subset of users and objects within the system.Volumes that are within the volume group must be within a child pool.

Ownership can be defined explicitly or it can be inherited from the user, user group, or from other parent resources, depending on the type of resource. A user cannot change the ownership group of the resource, but can change the ownership group of the parent object. The following rules apply to volume groups that are defined in ownership groups:

Volumes can be added to a volume group if both the volume and the volume group are within the same ownership group or if both are not in an ownership group. When migrating existing resources to ownership groups, the volume group and its volumes can belong to different ownership groups temporarily until the migration completes.
The ownership of a volume group does not affect the ownership of the volumes it contains. If a volume group and its volumes are owned by different ownership groups, then the owner of the child pool that contains the volumes can change the volume directly. For example, the owner of the child pool can change the name of a volume within it. The owner of the volume group can change the volume group itself and indirectly change the volume, such as deleting a volume from the volume group. Neither the ownership group of the child pools nor the owner of the volume group can directly manipulate the resources that are not defined in their ownership group.

Individual cloud volumes and volume groups have different statuses to indicate whether the volume is available for snapshot operations. These statuses can be used to monitor in-progress snapshots and error states for the snapshot. Cloud volumes have the following snapshot statuses:

Off: Transparent cloud tiering is disabled. Snapshots are not enabled for the volume or volume group.
Ready: Transparent cloud tiering is enabled. A new snapshot can be started for the volume or volume group.
Copying: Transparent cloud tiering is enabled. A snapshot operation is in progress and data is being transferred to the cloud.
Copying error: Transparent cloud tiering is enabled. An existing snapshot operation is in-progress and cannot be completed because of an error. Causes for copying errors include losing the network connection to the cloud service provider or exceeding the amount of capacity on the cloud storage. To determine the cause of the error, select Monitoring > Events in the management GUI or enter the lseventlog command to view either a concise or detailed view of the error log.
Not ready: Transparent cloud tiering is enabled. A new snapshot operation cannot be started because a restore is in progress for the volume.

In addition to creating snapshots of volume data to transfer to cloud storage, transparent cloud tiering also supports restoring volume data from cloud storage back to the system. Like with snapshots, versions of each copy operation are timestamped and stored on the cloud, which allows for specific point-in-time recovery operations to the original system or to another system. Older versions can be deleted and removed from the system and the cloud storage simultaneously to manage space. Snapshots can be restored only for individual volumes. You can restore multiple volumes simultaneously, but each restore operation needs to be started separately for each volume.

Certain recovery scenarios can require the restoration of an older version of the cloud snapshot. However, all newer versions on the cloud storage are deleted, including any in-progress snapshot operations. The management GUI verifies the version of cloud snapshot and issues a warning if the selected snapshot is not the most recent version. To proceed with the restore operation, you must confirm the deletion of these other versions. If you are using the restorevolume command to restore an older version of the cloud snapshot, you must specify the -deletelatergenerations parameter to delete all later versions of the snapshot.

You restore volume data with any snapshot version that was copied to the cloud, including restoring from a snapshot version that is still in progress. The snapshot version and volume that the snapshot version is being restored to must be the same size. A version cannot be deleted while it is being used for a restore. You can restore a snapshot version with following methods:

Restore to the production volume: If the snapshot version is restored to the production volume, which is the original volume from which the snapshots were created. The snapshot version replaces the current data that exists on production volume with the data that is stored on the cloud storage. The production volume goes offline during the restore operations. Data is not fully restored to the production volume until the changes are committed.
Restore to a new volume: When the snapshot version is restored to a new volume, you can use the restored data independently of the original volume from which the snapshot was created. If the new volume exists on the system, then the restore operation uses the unique identifier (UID) of the original volume. If the new volume does not exist on the system, you need to choose whether to use the UID from the original volume or create a new UID. If you plan on using the new volume on the same system, use the UID that is associated with the snapshot version that is being restored. You want a unique UID if you are restoring a version of a volume that exists on another system to the current system.

Individual cloud volumes have different statuses to indicate whether the volume is available for restore operations. These statuses can be used to monitor in-progress restore operations. Cloud volumes have the following restore statuses:

None: No snapshot version for this volume available for restore.
Available: Indicates that the selected volume has available snapshot versions on cloud storage that can be restored.
Restoring: Indicates that the restore is in progress for this volume.
Restoring error: Indicates that the restore operation is in progress, but an error occurred. Causes for restoring errors include losing the network connection to the cloud service provider or exceeding the amount of capacity on the pools in which the volume belongs. To determine the cause of the error, select Monitoring > Events in the management GUI or enter the lseventlog command to view either a concise or detailed view of the error log.