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.
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 the steps 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.