Synthentic full behavior on copy job

[ashleyw]

While I'm waiting longingly for Veeam 12.1.2 to drop and hoping it will provide experimental support for OpenZFS 2.2.4 with reflink block cloning support, I thought I'd run some tests on a new backup unit (24x16TB spindles of goodness) we have deployed in the last few days to revisit some very old issues.

So I ran an active full copy job and there was a single item in the job (out of 351) which had failed (because a VM had been deleted after the copy job had started).
Despite not selecting any synthetic options on the source job, the initial active full run through on the copy job came back with one failure out of 351. This was expected.

Presumably as the initial copy job didn't have a 100% success status, the next time the copy job ran, it again attempted a full copy, but strangely when i look at the status of the copy job each VM in the job says "Creating synthetic full backup" and as we all know regardless of infrastructure/topology the "Creating synthetic full backup" stage is extremely slow when not using block based cloning via XFS/REFS (please no!) as the files relating to each and every VM have to be ingested from the same device that is being written to.

When the job is running the per VM merges on large VMs with say 1TB of data drive, the process is very much longer than the smaller VMs which is understandable.

I just wondered if this behavior is expected as I don't understand why a copy job run through would trigger a synthetic full backup if that option was not selected in the copy job or on the main job.

thanks
Ashley

[Mildur]

Hi Ashley

would trigger a synthetic full backup if that option was not selected in the copy job or on the main job.

The source job doesn't affect synthetic full creation of a copy job. A synthetic full for a copy job is created when you enable GFS retention.

I suggest to ask support to check the logs. I'm positive that our support team can tell you exactly why it happened in your test.
Please let me know the case number for my reference.

Best,
Fabian

[ashleyw]

thanks Fabian,
It was exactly what you thought.
We had enabled GFS retention on the copy job a while ago which explains the synthetic full.
thanks again for clarifying behavior.