offsite replication

[dekkar]

Hi, I am trying to setup offsite replication of a 500gb vm.


I ran the replication to a external HDD, rather than use our 4mb link, and transferred the server onto the offsite storage.


When I go to run the job however, it looks like Veeam is just kicking off a first time replcation of the server, a whole 500gb copy.


If I look on the target lun I can see the VeeamBackup folder, then the server(vm-103) folder.

Inside this I can see the Server1_1.vmdk file that I copied over manually.

When I start the job I see a server1_1_working.vmdk of the same size.. Which I presume is Veeam copying down a completely new vmdk.


Has something gone wrong?

THanks,
Nathan

[Gostev]

Hi, nothing is wrong - everything works just fine. Please search this forum for _working.vmdk for more information about this file. Thanks!

[dekkar]

Hi, thanks for the reply... It seems it is working... But what I dont understand is why its replicating the complete VM across the WAN, when I ran through the whole "removable storage" method. Uploaded all the files to the remote lun then started the Veeam job again. Shouldnt it just be doing the delta changes? or whatever changes?

As it stands, the replication will take over a week! I planned for it to hopefully take less than a day (during the holiday periods when my network is doing nothing).....

THanks,
Nathan

[Vitaliy S.]

Hi Nathan,

Provided that you've configured everything correctly, then it should be an incremental run.

The processing rate you see in Veeam Backup console is not the actual transfer speed. The processing rate is calculated using this formula: Total VM size/Time (and so is affected by time required to perform guest processing, perform guest freeze, create and remove snapshots, backup smaller files).

Could you please tell me what it the WAN link connection you have to your remote site? What is the file upload speed from Veeam Backup server to the target ESXi host with vSphere Client Datastore Browser?

Thanks!

[Gostev]

Every replication job run after 1st (which can be done either over network or via seeding) will be incremental. Veeam replication simply does not have functionality to initiate non-incremental run when replica already exists on target.

Also, there are plenty of existing very recent topics about troubleshooting slow replication, one of them is just a few topics down, called "Slow Replica creation". I recommend that you review those topics as well first.

[dekkar]

Hi, the link to the target is 4mb. And in business hours it becomes our production link between sites.


Currently its at 46% and has been going for 4 days.

Veeam console tells me that is 46% completed at 788 KB/s.

Im not even sure if there is enough bandwidth to perform an incremental backup each night..... Possibly we will need a bigger link, still testing. Maybe its unrealistic to expect an overnight incremental replication of a server via the 4mb link?

My local vCetner doesnt have access to the remote SAN, so I cant really upload anything via the local vCenter datastore browser. They have their own vCenter server setup down there completely separate to us.

[Gostev]

It is very realistic to replicate daily over 4Mb link, but of course this depends on amount of servers and amount of daily changes in virtual disks of replicated VMs. There are no problems replicating a few fairly static VMs daily over such link. But replicating very active Exchange or SQL is probably not realistic.

Having WAN accelerator deployed (10x improvement) and using full ESX on target as opposed to ESXi (3x improvement) helps as well.

To perform the above-mentioned test, just open vSphere Client and connect to remote ESX (you replication target) by IP address, then perform the said test. You do not need vCenter or anything.

[Bunce]

Our experience is that the first run after seeding is quite slow, however you should be getting quicker than that.

we had a similar issue and noticed it was using port 902 which was due to it failing over to network mode.

Check your ssh credentials to ensure its logging in ok. also make sure you've installed the latest esx patches, particularly if using 4.0 as there was a fix for slow console performance from memory.

[dekkar]

Hmmmmm as far as performance is going... Its going as expected, I wasnt expecting too much..... The real issue I guess Im having is:

Shouldnt it be doing an incremental baackup? Why is it doing a full backup when I already manually copied it down there?

[Vitaliy S.]

Reading back through Anton's response above, every subsequent run after "seeding" or 1st run is incremental, otherwise your job would faile with an error message saying "there is no previous backup to perform an incremental run". Have you tried using any WAN acceleration tools?

Moreover, it is expected to have different processing rates for different types of VMs (DCs/Exchange servers etc.). Could you please tell what VM are you trying to transfer over that link?

[dekkar]

Hi, the VM is a file server. It doesnt do anything else besides hold documents.

Hmmmmm possibly I have misunderstood, thinking that its doing a complete backup, when its actually doing an incremental?

I just saw the Processed size: 243GB

After around 40-50GB, I just presumed it was copying down the whole VM. If the Processed size is the amount it has copied across the WAN, then its correct, I would expect 240Gb across the WAN to take 4-5 days....

I just didnt expect it to have to process so much data. Hopefully it isnt flooding the link and I can keep it running tomorrow!!!

[Vitaliy S.]

The processing size will always be equal to the sum of the VMs included to the job, so this is not the size of data being transferred. If I were you I would wait till your job finishes and then I would check out the size of the VRB file. It will show you the incremental data size, so you could compare this number to your estimations.