[V13] Failures on synthetic full

[ashleyw]

Hi,
I've been testing the V13 appliance.
Over the weekend when it was time for the weekly synthetics, the jobs failed with the following types of errors (64 out of 338).
21/09/2025 9:22:17 am Failed : Exception of type 'Veeam.Backup.AgentProvider.AgentClosedException' was thrown.

I want to run some more high load synthetic tests. Previously I was able to leverage the registry setting of;
HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\ForceTransform
Type: REG_DWORD (0 False, 1 True)
Default value: 0 (disabled)
Description: When set to 1, will trigger synthetic full on every job run
to force a transformation on every run to help me diagnose the issues.

How do I activate the same setting in the V13 appliance to aid with my testing?
Has the code/logic changed around synthetic fulls as part of the V13 migration?

I haven't seen this type of issue on V12 for months (except when I was narrowing down the ZFS integration with Veeam).

cheers
Ashley

[Mildur]

Hi Ashley

Technical issues: As per forum policy, a support case is required for technical issues. And V13 is a supported release. Can you please provide the case number with us?

Configuration parameter/registry key: Please see our Forum FAQ.


Best,
Fabian

[ashleyw]

thanks Fabian,
I'll try adding
ForceTransform=1
to the root section of the /etc/veeam/veeam_backup_and_replication.conf as soon as our back cycle is complete and then raise a support ticket, once I can reproduce the issue.

thanks
Ashley

[ashleyw]

hi,
Just to close the loop on this, the issue was not a problem with the Veeam setup, but rather a configuration issue on my side.
Just prior to the weekly synthetics, I had made a DNS change so that I could reverse publish both vCentre and Veeam console via haproxy (to make it easier for our internal users), so that the DNS entries pointed to haproxy rather than Veeam (Primarily so I could leverage cert handling on haproxy rather than having to configure certs within Veeam and vCentre).

The consequence of this was that it broke the flow during a backup cycle, so I created static entries for vCentre and Veeam (with their real internal IPs) and added them to the veeam console so the internal backup flow now prevents the traffic going through the proxy.
Thankfully the appliance model makes this easy to action from within the Veeam server appliance UI using the following approach;

# Override the DNS for the following servers (to ignore impact of reverse publishing)
* Log in as veeamadmin>
* Appliance console>Logs and Services>Host Configuration>/etc/hosts>Export
* Paste in the 2 additional entries (one for vcentre and other for Veeam) and save the file locally, then >Import
* Log off appliance, and log back in as veamso and approve the request
* Repeat for each of the 4 proxies and linux repositories in-case any communication relating to the proxies require DNS lookup directly to Veeam/Vcentre

so we are back on track and our Veeam V13 rollout is running great!