Timeout value for long backups

[miyu.masuda]

I want to get backup of the huge VM with multiple very large disks, but it failed after about 9 hours from the start of the backup.
※ VMs in the VCD environment
I have sent the logs to Veeam support and am currently confirming the cause and what to do about it.
Here, I would like to ask if there is a default registry in VBR that times out after a certain amount of time has elapsed since the start of the backup.

Regards,

[david.domask]

Hi miyu.masuda,

Please continue with the Support team and allow them time to understand the situation better. Without a review of the logs or a better understanding of why the timeout is happening, I don't think it's prudent to try and hope with registry keys.

Can you share a few more details about the VM and the situation?

- How big is the VM (across how many disks)
- What transport mode is used by the proxy? (NBD, Hotadd, DirectSAN/NFS)
- What is the bottleneck?

9 hours is a long time for the backup, but depending on the environment and the size of the VM, the processing time can easily be expected -- the main question is the "what" of the timeout, as if there is a misconfiguration or environmental restriction that limits the throughput, other approaches may be needed for this workload, but let's see what Veeam Support tells.

Additionally, can you please share the case number for our review?

[miyu.masuda]

Hello,
Thank you for the reply.

Of course, we will proceed to analyze the logs and determine the cause of the problem and take action on the job that caused the trouble.
I would like to see if there is such a thing as a specification.

The VM has 8 Disks of about 1 TB + system disk.

The transport mode is Hotadd.
Two VMware backup proxies (Windows VMs) handle this job.

The backup storage is DD and the primary bottleneck appears to be Target from the logs.
Also, the job error message on the VBR console is “Error: Exception of type ‘Veeam.Backup.AgentProvider.AgentClosedException’ was thrown.”

Case number is #07699855.

Regards,

[david.domask]

Thank you for sharing the information. With hotadd, the processing time seems a bit long based on those numbers, but let's see what Support tells. That the bottleneck is target however tells us that writing to the repository is the "busiest" part that we wait longest on -- similarly, based on the case notes, it doesn't look like a timeout, but the datamover agent closed unexpectedly, which Support will research and explain more.

So please continue with Support, I'm not confident a registry value will help here as looks like a review of the unexpected datamover agent closure is required.