Release: February 14, 2023
General
- This release supports Purity/FA 6.1.0 and higher
- This release is supported with Veeam Backup and Replication version 12+
- Volumes that are to be replicated through Asynchronous replication to a secondary FlashArray needs to be configured so that they will be detected by the Veeam plugin as "ready for replication". The volume must be part of a protection group where the secondary FlashArray is a target.
- Volumes that are to be replicated to an offload target need to be configured so that they will be detected by the Veeam plugin as "ready for replication". This can be done by ensuring that the volume is part of a protection group where the offload is a target
- This plugin version supports ActiveCluster
- This plugin version does not support ActiveDR
- Please follow the guidance found here with leveraging Safemode features on the FlashArray.
What's New
-
Support for Universal Storage API v2, which enables the following additional functionality:
- Snapshot replication orchestration: Allows backup jobs to leverage existing Everpure FlashArray Replication relationships to create storage-based snapshot replicas as additional restore points. This also enables performing backup from secondary storage arrays, to avoid any load from backup activities on the primary storage array.
- Snapshot archiving orchestration: Allows backup jobs to manage the offload of volume snapshots to a different type of storage device via Everpure FlashArray Offload functionality and track them there as additional available restore points.
- Synchronous replication support: Allows backup jobs to create coordinated storage snapshots and track them as additional available restore points and perform backup from volumes on both sides on dual Everpure FlashArray ActiveCluster configurations that serve the same production volume from multiple storage management backends.
Fixed Issues
- Previous issues when using Safemode with Purity//FA have been addressed in most cases. However, please refer to the specific guidance and recommendations when using Safemode with the Everpure plugin for Veeam.
Known Issues
- Volumes that are part of a Volume Group are not supported for asynchronous snapshot replication.
-
Backup job fails for FlashArray that are running Purity//FA under 6.1.0
- Description:When running any non-replication Job, the job fails with the error "Failed to create snapshots on primary storage: Message from Purity='ctx:Supported versions: 1.0, 1.1,..."
- Cause:VBR Plugin 2.X supports only Purity//FA 6.1.0 or higher. However, the plugin is missing a check for the Purity//FA version on some operations, which causes the process to fail when trying to do any REST calls. This causes the error message not to be very clear.
- Solution or Workaround:Update to Purity//FA 6.1.0 or Higher.
-
Replication Backup job is created successfully, but snapshots don't replicate
- Description:Veeam User can create a backup job with replication to secondary. When running the job, the job succeeds with the warning "Cannot Find Snapshot Replication Relationships". Snapshot is not replicated to target.
- Cause:Replication is not configured on the FlashArray's
- Solution or Workaround:For the replication to work, user has to create a protection group including the volume that will be used at the job, and set a target Flash Array (or Offload Target). The Target Array also need to be added to the Storage Infrastructure on VBR.
-
Replication is configured, but snapshots do not replicate
- Description:Protection group with replication target are setup properly. Both source and target Flash Arrays are added to VBR. Backup Job succeeds but throws the warning "Cannot Find Snapshot Replication Relationships". Snapshot is not replicated to target.
- Cause:The way it works is that VBR runs discovery on the FAs every so often, so it keeps an internal list of volumes that exist on each FA. When we run the backup jobs we will return the replication profiles that we find. VBR will then try to find a match for the replication volumes listed on the replication profile with this internal list. This is the step that is failing. That happens because the replication didn’t exist the last time VBR ran discovery on the target FA.
- Solution or Workaround:Make sure replication is configured correctly. (You should see the replication pgroup as a "target pgroup" on the target flash array) Rescan the target FA on VBR, a volume named "sourceFA:volumename" should appear. To improve this behavior, a change has to be made on the VBR side.
-
Volume with multiple target FAs only replicates to one
- Description:For example, there are two array protection groups each with a different target, and the protection groups could have some common volume as well, the expected behavior is to replicate on both the target. However, when the Veeam backup job runs, the plugin only replicates to one of the targets
- Cause:From the array perspective replication does trigger to both targets, but Rollback is being called from Veeam to only one of the targets. In turn the replicated snapshot is being destroyed. Replication status returns completed for both profiles, then VBR calls CommitReplicationSession for one target but RollbackReplicationSession for the other. According to Veeam this is by design for this version of VBR and they have plans to support that scenario in the future.
- Solution or Workaround:At this time, there is no workaround. Volumes with multiple targets could have inconsistent or failed results. This issue is being worked on by both Everpure and Veeam to improve in forthcoming versions.
-
Volume is in a Purity protection group, but async replication is not occuring
- Description:Protection group with replication target are setup. Both source and target Flash Arrays are added to VBR. Backup Job succeeds but throws the warning "Cannot Find Snapshot Replication Relationships". Snapshot is not replicated to target.
- Cause:The array volume and array protection group were part of a Pod. The purevol send does not support pod volumes, so the plugin cannot replicate the volume
- Solution or Workaround:Unsupported scenario. Bring volume/s and protection group/s outside the pod.