Replica Metadata Behavior and Verification after Terminated Jobs

[matsusan]

I have a few questions regarding replica metadata (digests) behavior when a replication job is terminated prematurely.

My Understanding:

• Metadata Generation: Replica metadata is generated and updated dynamically during a replication job.

• Valid Metadata: If the metadata is consistent and valid, the next run will perform a CBT-based incremental read.

• Invalid/Corrupted Metadata: If the metadata is invalid, the next run forces a fallback to a full read/scan.

Questions:

• If a job is terminated prematurely (canceled or stopped), is the metadata generated during that session flagged as invalid?
  Or can it be partially saved as valid depending on when it was stopped?

• Is there a way (via logs, GUI, or PowerShell) for users to verify:
  - If the metadata was successfully saved after a terminated session?
  - Whether the next run will be an incremental or a full read based on the metadata state?

Thanks,
Ryoma

[david.domask]

Hi Ryoma,

Your understanding is mostly correct; typically an aborting error on the Replica job will not trigger Digests Calculation. The usual culprits for this are when the target replica has been altered externally and Veeam needs to verify what blocks already exist for the target replica or when the replica metadata on the selected repository has been corrupted.

To answer your questions directly:

1. Typically no, but this will heavily depend on the nature of the error. (e.g., if there is issue writing digests to the metadata / the existing metadata has become corrupted, that will trigger Digests Calculation. Network errors or hypervisor errors typically will not)
2. No method exists. If you experience an unexpected Digests Calculation, open a Support Case and allow Veeam Support to review the debug logs to understand the root cause of the Digests Calculation.

[matsusan]

Hi Domask,

Thank you for your help.

Could you provide any summarized information regarding the conditions that trigger a digest recalculation?
We want to inform our customers in advance that digest recalculation can prolong replication times.
Therefore, having detailed information about these conditions would be highly useful.

Thanks,
Ryoma

[david.domask]

Hi Ryoma,

You are welcome.

For your clients, please advise:

- Ensure that the replica metadata is present in the location configured in the job (if they move the metadata without re-configuring the location, typically it is fine to stop the job, adjust the metadata location, and then start the job again it will resume with the existing metadata)
- Ensure that the replica metadata is consistent and does not get corrupted (not much you can do if this happens, in theory you can make a copy elsewhere manually but this is not an official recommendation)
- Do not manually alter the disk configurations / sizes on the replica
- If you need to change the disk configurations (i.e., size) on the source VM, consider simply starting a new replica as this action will result in all replica restore points being removed, and the subsequent replication run may be considerably longer
- Changing the Data Source for replication always triggers Digests Calculation, so do not change this option without reason, as even switching back to the previous option after the job has started will still require Digests Calculation

There may be other non-configuration related reasons that Digests Calculation gets triggered and these will require a Support Case to investigate. I cannot tell whether or not such instances can be prevented, so please prepare your clients that in some cases if Digests Calculation is taking too long for known / not yet known reasons starting the replica fresh is typically the best option and to prepare for this.