Retention parameters define an amount of time for cloud data to remain in cloud storage after the related SmartLink file is deleted.
When CloudPools archives a file from your cluster to cloud storage, it creates a SmartLink file on the
PowerScale cluster in place of the archived file. If the archived data remains in the cloud, the SmartLink file remains in place to represent and access the cloud data.
If a user deletes or recalls a SmartLink file, and all other references to that cloud data (such as snapshots taken while the file was archived) are removed, the cloud data that is associated with that SmartLink file becomes eligible for garbage collection. CloudPools deletes the data from cloud storage, but not immediately. A calculated deletion date is associated with each SmartLink file. The deletion date determines the time that must pass after the SmartLink file is deleted or recalled before the cloud data is garbage-collected. Retention parameters determine the deletion date.
Retention parameters and the deletion date are important when you are using SyncIQ or NDMP backups.
A SmartLink file might be backed up to tape through NDMP or replicated to another
PowerScale cluster through SyncIQ. More than one SmartLink file can point to the same cloud data. Users might use a restored or replicated version of a deleted or recalled SmartLink file to access the cloud data. Depending on the deletion date, the supporting cloud data might be deleted. In these situations, the data is unreachable from the backup or replicated version of the SmartLink file.
Retention parameters are configurable. Short retention times are likely to cause the cloud garbage collection to occur before a user attempts to access the data using a restored or replicated SmartLink file. Longer retention times give your organization more time to ensure that a restore would work as expected. In general, if you are backing up or replicating SmartLink files, do not set small values in the retention parameters.
The following sections describe the retention parameters and how CloudPools uses them to calculate the deletion date.
Retention parameters
The following archive policy retention periods affect the deletion date:
Cloud Data Retention Period specifies the retention time of cloud data beyond the time when an associated local SmartLink file is deleted or recalled, leaving no file references from the local cluster. The default setting is one week.
Backup Retention Period for NDMP Incremental Backup and SyncIQ specifies the retention time of cloud data whose SmartLink file is backed up by an incremental NDMP backup, or replicated by a SyncIQ operation. If a local SmartLink file is deleted, you can restore the SmartLink file copy, and access the cloud data. The default setting is five years.
Full Backup Retention Period for NDMP Only is the retention time of cloud data whose SmartLink file is backed up by a full NDMP backup. If a local SmartLink file is deleted, the SmartLink file copy is restored from the backup, and users can access the cloud data. The default setting is five years. See
Deletion date calculations
for more information.
When a SmartLink file is replicated to a secondary cluster and is then deleted from the primary cluster, CloudPools considers all those settings to determine when to delete the associated cloud objects.
CloudPools first determines which workflows affect the deleted file. CloudPools considers only the settings that apply to the relevant workflows. For example, if an NDMP file was never fully backed up, CloudPools does not consider the
Full Backup Retention Period for NDMP Only parameter to determine when to delete associated cloud objects for that file.
CloudPools uses the longer of all the appropriate durations to determine when to delete cloud objects.
If you delete a SmartLink file on the secondary cluster (because the primary cluster is temporarily unavailable), the deleted state remains in cache. When you fail back to the primary cluster, CloudPools deletes the SmartLink file. CloudPools uses the retention settings to determine when to delete the associated cloud data.
You can view retention values using the following command:
Each retention parameter is a delta time in seconds. When certain events happen, one of the retention values is added to the current time to create an absolute future time. If the new time is farther in the future, it becomes the new deletion date.
The new deletion date is calculated as follows:
When SyncIQ or NDMP copies a SmartLink file, either the
Backup Retention Period for NDMP Incremental Backup and SyncIQ or
Full Backup Retention Period for NDMP Only value is used to calculate the new deletion date. This calculation only applies to when a file is part of a SyncIQ job or NDMP backup. If the file has not changed, and thus is not backed up, the deletion date will not be updated.
When the file is recalled, the
Cloud Data Retention Period value is used to calculate the new deletion date. This occurs regardless of whether the file was previously backed up using SyncIQ or NDMP. In other words, the later of the current object deletion or garbage collection time for the file or the current time plus the Cloud Data Retention Period are used for the garbage collection time. For example, if a SmartLinked file was last backed up over 5 years ago (default) and is then recalled, the new garbage collection time will be 1 week (default Cloud Data Retention Time) beyond the time of the recall.
When a file is deleted (and all references to that file are removed - i.e. snapshots that contain changes to that file), then the greater of the garbage collection time or the current time + Cloud Data Retention Time is used to determine the new deletion date.
Garbage collection occurs after the deletion date. The cluster that has cloud access to the cloud account that archived the file performs the garbage collection. See the
isi cloud access add command.
Attempts to read a SmartLink file whose cloud data was garbage collected fail. For example, a SmartLink file on a SyncIQ target cluster does not work if the cloud data was deleted. Similarly, a SmartLink file that is restored from an NDMP backup does not work. This situation typically occurs only if the policy on the SmartLink file uses small values for the retention parameters.
Data is not available for the Topic
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\