Why are digests calculated when last replication job failed?

[mcz]

I'm wondering why veeam calculates digests if the last replication pass wasn't successful. AFAIK veeam creates helper snapshots during replication and if an error occurs or the job is being aborted, the vm will be reverted to the "base" snapshot and the helper snapshot will be removed. That means that you do not have a curruption within your disks.

The second thing I know is that CBT can only be used "from snapshot to snapshot" but where is the difference between replication and backup? I mean if you abort a backup job and start it again, CBT will still be used allthough the last backup job wasn't successful. Why can the same behaviour not be transferred to a replication job?

Tnx!

[DGrinev]

Hi Michael,

I discussed your issue with the dev team and they confirmed digests recalculation shouldn't be triggered by replication job fail.
Also, the replication job should use CBT similar to the backup job behavior.

Please, contact our support team for detailed investigation of unexpected digest recalculation. Don't forget to share with us the case ID number.

Thanks!

[mcz]

I discussed your issue with the dev team and they confirmed digests recalculation shouldn't be triggered by replication job fail.
Also, the replication job should use CBT similar to the backup job behavior.

Thank you Dmitry for your message. Hmm, maybe I'm little bit confused about this... I think there are two different things to consider:

• Calculating digests (e.g. in case of increased disk size of the source vm)

• Reading whole content of source disk (do not use CBT)

I checked it again and the last entry is the case when the job hasn't been successful before. In the history I can see a replication job, which is titled as "Retry 1", which has the following entry within the job details:

Cannot find dirty block information in the previous restore point, CBT will not be used

Why is CBT not used when the job failed before? As I mentioned before, I cannot see a differenct between replication and backup if we are talking about this behaviour.

Thank you, Regards
Michael

[DGrinev]

Hi Michael,

You are right CBT should be used for the replication.
That's why you should take a closer look on the issue with our technical support and share the case ID number here for us to be in touch. Thanks!

[mcz]

Hi Dmitry,

case #02155842

[mcz]

Hi Dmitry,

just wannted to give you a short update about this case. Basically, metadata was corrupted and because of that, the whole chain had to be created again - that is understandable.
But then I realized that veeam shows "metadata corrupted" even if just the repository isn't available. Next time when the repo is available, digests have been calculated again.

Nobody was able to tell me exactly, why the chain has to be calculated again. I mean if you just hear "metadata is corrupted", I do not understand why you have to calculate the whole chain again. Remember if you do a backup job and say suddenly the repository gets disconnected, veeam will do a retry and just do another incremental backup. If you do a replication job and metadata is being calculated (because of deleted blocks and swapfile) and it fails, why not just start the job again and start metadata again, where is the problem?

[foggy]

Nobody was able to tell me exactly, why the chain has to be calculated again.

Because without metadata we cannot make sure the existing backup is not corrupt either.

[mcz]

Thank you foggy for your reply. Yes I know that metadata is needed, of course. But why is whole chain being calculated and not only the last restore point? Why is it possible to just retry a backup job (if something went wrong before) and backup will just do the incremental job and in case of replication the entire disk has to be read again?? I know it has to be read because of rebuilding the metadata, but again: WHY THE WHOLE METADATACHAIN AND NOT ONLY THE LAST RESTORE POINT?

And then why gets metadata corrupted (veeam tells you that on the next retry) when only the repository on which the metadata is stored wasn't available since the job started (that cannot be because only if the files are not available, they cannot get corrupted, right)?

[foggy]

But why is whole chain being calculated and not only the last restore point?

The 'metadata corrupt" message means that the entire metadata needs to be re-calculated, not just for the last single increment.

And then why gets metadata corrupted (veeam tells you that on the next retry) when only the repository on which the metadata is stored wasn't available since the job started (that cannot be because only if the files are not available, they cannot get corrupted, right)?

There definitely should be a more serious reason of the corruption (storage failure, for example).

[ortoscale]

in my case last job didn't fail, i've just removed VMs last disk from replication because we decided that it's not needed, and now is calculating digests

[foggy]

Hi Matjaž, digests calculation is not expected if you've just added one of the source VM disks into exclusions.