Retry of replication job uses newer restore point

[FrancWest]

Hi,

We are using replication jobs to build or update our lab environment. Sometimes a VM errors out during replication and you have to retry the job after correcting the reason for the failure. However, it appears that when veeam retires the job for the vm that failed to replicate, it uses the newest available restore point for that vm instead of the original one. This might cause some issues:

- since the replication job may take several hours, sometimes even a day, the computer password for Active Directory might have been renewed. When veeam replicates this vm it can loose contact with AD because it's password doesn't match anymore (the DC'S were replicated on the first run) and you have to re-join the vm to the domain.

- when retrying a VM that is part of an Exchange or SQL DAG, you might end up with a mix of newer and older databases. This causes issues with replication between other DAG members and you have to initiate a re-seed which also can take many hours.

So my question is: why doesn't veeam use the same restorepoint that was used initially when retrying a replication job? Or at least let there be an option to specify which restore point to use for the replication.

Franc.

[Vitaliy S.]

Hello Franc,

So my question is: why doesn't veeam use the same restorepoint that was used initially when retrying a replication job? Or at least let there be an option to specify which restore point to use for the replication.

Not sure that I am following the issue here. The original snapshot is the oldest one. If replication job fails, it removes the "corrupted" restore point and creates the new one based on the changes happened starting from the previous snapshot (restore point).

Thank you!

[FrancWest]

It's not that the entire replication job fails, but only a couple of vms. When the job is retried, a newer restore point is being used for those vms.

[foggy]

Previous restore point contains invalid data, so new restore point is used. It actually doesn't matter which restore point is used, since actual VM data at the moment retry occurs is copied anyway.

[FrancWest]

It sure does matter. If a retry is done for one or more VMs of the replication job, a newer restorepoint is used for these specific VMs. Since all other VM's were replicated fine, those are not copied again during the retry. Now, when this specific VM has for example changed it's password in AD during the first run of the replication job, it can't connect to AD anymore and you have to manually intervene, since the domain controllers replicated on the first run contain the old password for that VM. Same goes for DAG members. If one dag member fails to replicate on the first run, it contains a newer database on the second run (because of the newer restorepoint being used) than the other exchange servers replicated on the first run. That's what I'm trying to explain here.

I had this experience myself before I posted this message. I had to reseed the Exchange database since DAG replication failed because the newer database didn't have the transaction logs anymore needed for successful DAG replication.

[Vitaliy S.]

Hi Franc,

I see your point, but all VMs processed within a single job already have a different time of quiescence and snapshot creation. In other words, a retry for the failed VM is equal to the situation when you have lots of VMs in the job and the latest processed VM has a different timestamp compared to the previous one.

Thanks!

[FrancWest]

Hi,

Sure, but in that situation we are talking about seconds or minutes at most (we are using backup from storage snapshot). When replicating it takes hours or even a day before you can retry the job (you can only retry if the job has finished). So the chance that the issues I'm describing occurs is way less smaller in the situation you describe.

[foggy]

But how do you suggest to perform retry then? Using some old data as of the time the first job run occurred? But the VM has changed since then already. Veeam B&R captures the current VM state, it cannot go somewhere in past.

[FrancWest]

We use restorepoints created by backup jobs as the source for the replication. So why can't it use an older restorepoint to do the replication, they are available.

So indeed use the same restorepoint that was used when the replication job started. It's important that all VM's are from around the same timestamp to prevent the issues I'm describing.

[foggy]

Well, you never mentioned you're doing replication from backup.

[FrancWest]

Sorry, but I gave a hint here 'Sure, but in that situation we are talking about seconds or minutes at most (we are using backup from storage snapshot).'

[foggy]

This could mean you're replicating right from the storage snapshot, not backing up from storage snapshot and then replicating from those backups. Anyway, now I got your concern.

[FrancWest]

Ok, sorry for the confusion then.