Challenge
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 VM to be replicated, which is different from the ID of the replica.
Solution
These steps must be performed by a Cloud Connect Service Provider.Tenants who are unable to map replicas should ask their service provider whether this workaround is available.
- 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_replca.
- 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 steps 6-9, below.
These steps must 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.
- 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.