Hourly Veeam Replication

[r.mckeon]

My setup is: 2 ESXi hosts with vCenter, 4 VMS (total of around 2.5TB together), sitting on shared iSCSI storage (Synology NAS). We also have an extra Synology to use for backups/replication.

I'm planning on using Veeam Replication jobs every hour in order to keep near real-time replicas of 1 of my VMs, and daily replicas of the other 3. I would also have daily backups (reverse incremental), with weekly full backups of all my VMs, with restore points going back a week in order to cater for users mistakenly deleting files etc. For the replication jobs I will only keep 1 or 2 restore points, as the point of the replicas will be for quick failover.

I have two questions re the replication jobs:

1. Replicas seem to work kind of like forward incremental backups, in that you transfer the entire VM the first time but after that simply add on increments with the changes. But will replication jobs ever need to fully transfer VMs again? What I mean is that, with forward incremental backups, it is recommended to have weekly full backups in order to protect the integrity of the backup files...is this required/possible with replication jobs?

2. Replication jobs require that a snapshot be created and subsequently removed on the production VM. Removing the snapshot freezes the VM every time, sometimes for a few minutes. If I were to carry out replication of a VM every hour this would mean a few minutes of downtime every hour, which is unacceptable. Is there any way around this?

Thanks!

[Vitaliy S.]

Hello Rick,

1. Replication jobs are forever incremental. In other words you will not need to run active fulls, so the answer to your question is no, full job passes will not be performed.

2. VM stun issue might be resolved by giving more resources to your source VMs, migrating them to the storage with fast disks, or using SAN snapshots (for example, integration with HP storage), other than that nothing else comes to my mind. BTW, if you search these forums for "snapshot removal tasks" you will see an existing topic, that has some other recommendation on this matter.

On a side note, I would suggest keeping at least 2 restore points for your replicas, because this will allow you to avoid situations when source VM gets corrupted and the configured replication job syncs this image with the DR image/replicated VM.

Thank you!

[r.mckeon]

Thanks for your reply Vitaly.

I had already looked through the forums, both Veeam and VMware, but the issues people were having were mainly from outdated versions of vSphere and Veeam, which is not the case in my scenario as I have the latest versions of each.

[Vitaliy S.]

VM stun can see be observed with latest versions of vSphere. Do you see the same behavior for all VMs being replicated?

[r.mckeon]

Yes, it's consistent throughout the VMs. The stun is by design from VMware.

[Vitaliy S.]

Snapshot commit issue usually happens if you have a large snapshot to commit, so reducing the replication interval might help. Need to give it a try.

[r.mckeon]

It does reduce the interval, but that's not my point. The fact that there even is an interval is disruptive, don't you agree? Even if it's just 1 minute...one minute with a stunned Exchange or SQL server can cause problems, or am I overthinking?

[Vitaliy S.]

1 minute is definitely an over-kill .... but you're right, some time can still be required to commit the snapshot.

[Gostev]

one minute with a stunned Exchange or SQL server can cause problems

Snapshot commit process will never be able to keep the VM stunned for so long. The longest I saw on the slowest lab (virtual ESXi running in a VMware Workstation on a desktop) was a few seconds according to the VM logs. If ESXi cannot commit the final delta during this period, it simply creates the new delta file for the following writes, releases the VM from stun, and moves on to committing the previous delta. Then, it tries the process again and again on newly created deltas. This is easy to see in a lab with slow storage if you initiate large file copy within a guest before initiating snapshot commit.

[r.mckeon]

Thanks for your replies. You've helped to clear things out, but after some testing I've personally found Veeam Replication to be too taxing on my storage. I will probably go for vSphere Replication 5.5. Overall Veeam Replication looks like a better product, but my storage cannot cater for the heavy hit that is incurred when using VM snapshots. Veeam have a great replication product IF and only IF you're willing to spend on good storage. vSphere Replication may not be as feature-filled as Veeam Replication but at least there is no visible impact on production VMs, and backup integrity has been improved with the new restore point feature. I will use vSphere Replication for instant failover (in case of a disaster) and Veeam Backup for file-level restores (in case of accidental data loss).