backup fails after expanding source disk

[scottmlew]

(case 04643536)

My first normally scheduled incremental failed after expanding one of the disks by 16GB. That resulted in this message for the original attempt and all retries:

Processing machinename Error: Input/output error POSIX: Failed to read data from the file [/dev/sdb]. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: Input/output error POSIX: Failed to read data from the file [/dev/sdb]. Unable to retrieve next block transmission command. Number of already processed blocks: [906]. Failed to download disk 'machinename-flat.vmdk'.

Today I tried to manually process a full backup, and that still failed, but with a somewhat different error message:

Error: Input/output error POSIX: Failed to read data from the file [/dev/sdb]. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.

I am running Veeam Backup & Replication 10.0.1.4854 and the VM being backed up is Ubuntu 20.04.1 LTS running on ESXi, 6.5.0, 7967591

Any ideas? This is all happening locally, on a solid network, so the posts about networking problems don't seem to apply. Also, the last processed block is always the same.

[PetrM]

Hello,

I assume you back up the workload using Veeam Agent for Linux in managed mode? Did you try to process it as a virtual machine and to add the VM into the job from vSphere server?

Thanks!

[scottmlew]

@PetrM no, it is being backed up as a VM

[scottmlew]

I've now rebooted the proxy and am still getting the same results. Interestingly, I get different error messages for some of the attempts. The original attempt plus retry 4 got the shorter message I posted above, and retries 1, 2, and 3 all got the longer message.

[PetrM]

I would recommend to continue working with our support team in to figure out the root cause of this behavior.

Thanks!

[scottmlew]

For anyone running across this thread -- this ended up being due to a read error on the RAID hosting the VM being backed up. In this case, /dev/sdb is the VMDK that was hot-added to the proxy, and that is what could not be read.