Local initial sync replication

[aqualityplace]

We are setting up a DR solution for our customers. We have an vsphere environment at our Datacenter and our plan is to use this in a many to one configuration. So we will have lots of customers replicating to our ESX servers.

For security reasons we are palnning on hosting a single veeam instance on our environemnt which will be managing the customer ESX servers. We will add the required CPU licenses to our veeam instance as we add customers. Does this sound like the correct way of implementing this.

Many of our cutomers have slow links so our plan was to create a local replica and copy this using removable storage to our Datacentre. I thought I read somewhere that this would be possible, but I cant find any documentation for this process - Is it possible?

Thank you

[Gostev]

Michael, we do support using removable storage for the initial copy (see page 55 of the User Guide), however it assumes that Veeam Backup & Replication is installed in the source site. If you install Veeam in the target site, the initial copy process will pull the data over WAN. So you cannot really use this functionality in your scenario.

Did you consider installing Veeam Backup locally in your customers environments instead, and using Veeam Backup Enterprise Manager to control all customers deployments from a single UI?

[Gostev]

Moved topic to the Veeam Backup & Replication forum.

[aqualityplace]

thank you for the fast reply - Our concern is that by installing the veeam product at the customer site they would be able to open up the console and access the esx targets. As this would be a shared environement we didnt think this would be a good plan

[aqualityplace]

not sure if this will work - take an esx host to the customer site add the source and target esx hosts to veeam located at our datacenter. Perfrom the first replication ( is the the replication is direct between esx hosts, the veeam server doesnt act as a proxy) then pause the replication job

Then take the esx host to our DC, copy the replica to another esx server with the same name and password details, register the VM on the new target host. Update DNS at the customer site to point to the new IP of the esx target and restart the replication job

how crazy is this plan?

[Gostev]

Correct procedure for the workaround you propose would be this: setup the job between ESX hosts located in source (customer) site, run first replication, move the produced files manually to the target ESX in your environment, then change replica destination in the job wizard.

That will work, but both hosts have to be "fat" ESX (not ESXi), and you should use "Network" service console agent processing mode (last bullet) for the initial job to enable direct operation between ESX hosts (you would want to change this to vStorage API later for faster replication).

Thanks!

[aqualityplace]

excelletn. our curetn target hosts are esxi but we could deploy a new esx blade for this job, thank you for your help

[aqualityplace]

We may have a problem with future customers runnign esxi. If we went with your orginal plan and placed a local veeam server at the customer site, could we create a customer veeam permision role so they can only see their dedicated LUN VMFS on the target server - would this be possible?

[Gostev]

LUN access permissions is actually part of SAN configuration (SAN may or may not have this feature). Some SAN do provide ability to limit access to LUN to specific hosts only, so this may help you. You should check on that with you SAN vendor.

[aqualityplace]

with vsphere you can set permissions on the VMFS? this was my understanding. The replication will be across the network so access to the luns would be via an esx host