Backup of Linux VM

This usually indicates there are issues with the data store or the Veeam proxy’s connection to it. Which transport mode are you using for backup?

To check VMDK integrity on the datastore, try to migrate the vm to another data store and back to the original. This should show whether there are problems with the vmdk or the datastore.

This kind of I/O device error can sometimes be related to issues with the VM’s VMDK file, such as corruption or problems accessing the underlying storage. As a test, try migrating the affected VM to a different datastore using Storage vMotion if available. This process can help identify or even correct silent issues with the disk. After the migration, run the backup job again to see if the problem persists. It’s also worth checking if the flat VMDK file is accessible and not locked or reporting any anomalies in vSphere.

Also, check the disk type, thick vs. thin, and make sure they are supported and not having compatibility issues.

Hi ​@Toller Emil there are a lot of similar posts as 

THIS ONE

Please check other info and let us know if you solved. 

I find it a little strange that this is only happening for Linux systems and not windows. Does this job have guest processing enabled in any way? Application-Aware processing or file indexing? Does the issue go away if that is disabled?

Application-Aware processing or file indexing is not enabled.

vMotion between storage works fine. But Backup error still occured.

Can you share whether this is the initial backup of those vms, or an incremental backup? Does an active full succeed on these vms? You can Perform an Active Full Backup for Individual Workloads if you don’t want to do an active full for the entire job.

I only try the “Active full”. There has never been a successful backup done.

maybe you can describe, what is different between windows and linux like

there are in the same backup job?

or do you use agents?

do you same datastore, resource pool? if not, try to migrate one linux VM to the group of windows VMs - potentially could be size of VMs - not enough space to crate snapshot ...

could be that you have linux VMs in different cluster? so issue could be that you are using dedicated proxy servers?

maybe you can try to untick checkbox to not quiesce VM during backup - then you have an issue with pre-freeze and post-thaw scripts in /usr/sbin of linux VMs