Replication times

[Simon_260917]

Hello all,

I've created a replication job using v 9.5. I'm replicating a single Windows server VM (500 Gb) and keeping one restore point.

The first evening the job took 11 hours to complete (reading 436 Gb) for the first full copy, processing rate 20Mb/sec.
The second evening the job took 90 minutes to complete and read 57.8 Gb processing rate 20Mb/sec
The third evening the job took seven hours to complete and read 439 Gb processing rate 20Mb/sec

My question is why did the third evening take so long and need to read the whole VM like it did on the first evening? Does this have something to do with snapshots being deleted and replaced?

Many thanks

Simon

[foggy]

Hi Simon, could you please check whether CBT was used during the third job run? You can check it in the job session log, select the VM to the left and look for the [CBT] tag in the disk processing records.

Also, it is always a best practice to have more than one restore point, since with just a single restore point retention you're at risk to be left without any of them at all.

[Simon_260917]

Hi Foggy,

Yes, on all occasions CBT was being used.

This morning the same job ran and it read 215 Gb which equates to half the size of the VM/drive

We wanted to migrate the VM off a failing drive so needed just a minimum of restore points.

Thanks

Simon

[foggy]

What kind of VM it is? Does it run any applications that might explain high change rate inside the guest OS? Any chance Windows Deduplication is enabled inside?

[Simon_260917]

Its a 2008 r2 server. It does experience a very high change rate during office hours but minimal between 11 pm and 7 am. I just thought that Veeam maybe doing something funky. Windows dedupe is not enabled. I'm going to run a native vsphere clone tonight whilst powered off. This should be a quicker method for getting it off one drive and onto another without the use of snapshots.

Thanks for your help.

[foggy]

Veeam B&R just copies all the changed blocks to the target VM. You can use planned failover, if your main concern is migration of this VM to another storage.