Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
This KB article documents the procedure for mapping a replication job to a replica that was not created by a tenant's replication job. Use case examples: The tenant has sent backup files to the Service Provider, and the Service Provider restores the VMs from the backup files to create replication mapping targets. The Service Providers environment has been impacted in such a way that the hypervisor reference IDs have changed and the tenant's job can no longer find the previously existing replicas. When creating a replication job, seeding or mapping can be used to minimize the amount of traffic sent to a Cloud Service Provider. In most cases, seeding is the preferred method because it is not possible to map a Cloud Connect replication job to a replica that was not created with Cloud Connect. However, it is possible for a Cloud Service Provider to work around this limitation by replicating the existing replica.Note: It is not possible to use a backup of a replica as a seed, because Veeam searches the backup file for the ID of the source VM, which is different from the ID of the replica.
Tenants who are unable to map replicas should ask their service provider whether this workaround is available. Steps to be performed by the Cloud Connect Service Provider. Connect a console to a Veeam backup server with access to the infrastructure containing the original replica. Typically this will be a backup server with a per-socket license, and not the SP Veeam backup server used to provide cloud resources to tenants. Use the tenant’s credentials to connect to a cloud gateway . Create and run a job to replicate the original replica into the cloud infrastructure. When configuring the job, consider that adding the default suffix will result in VMs named *_replica_replica. Delete the replication job created in step 3; do not delete the replica. Remove the service provider that was configured in step 2. Advise the tenant to proceed with the steps below. Note: The console used for these steps may still display the replica after the service provider is removed in step 5; the replica should not appear the next time the console is opened. Steps to be performed by the tenant. In the Backup Infrastructure view, add or rescan the cloud service provider. Verify that the replica is visible in the Replicas node of the Backup & Replication view. Press F5 to refresh the view if needed. Map the replica to a replication job. This must be done manually; the Detect option is not available. Run the mapped job and test the replica. Let the service provider know that they may proceed with the final steps. Steps to be performed by the Cloud Connect Service Provider. Both SP and tenant will see duplicate replicas (with different source VMs) in the console. To resolve this, the SP must remove the older replica from configuration . (Optional) When the new replica has been tested successfully, the Service Provider may delete the original replica that is no longer needed.