Host-based backup of VMware vSphere VMs.
Post Reply
FreddyN
Influencer
Posts: 15
Liked: 1 time
Joined: Jul 28, 2020 11:35 am
Full Name: Freddy Neuhaus
Contact:

Corrupt Backupfiles after move to new repo

Post by FreddyN »

Hello

My Case is #05140714.

We have problems after switching to new reps. The Corrup backupfiles don't show up instantly after copying files to new repo. Sometime we have 2 successfull runs, other jobs failing after 1 week.
The repo is still the same NAS, We reduced the old partition to add a new iSCSI-Lun. Afterwards we made a copy of the existing backupfiles to the new LUN and mapped this files to new Jobs. So far, so good.
Now we are getting into trouble:
Most of the jobs give us:
- Agent: failed to process method {Transform.Patch}: The parameters is incorrect. Failed to read data from the file [PATH]
- Processing VM-NAME error: Failed to reload metadata bank. Decleared and actual CRC are differnet for all bank snapshots. Failed to open storage for read access. Storage:[BACKUPFILE]. Failed to open strorage for read access. Storage [BACKUPFILE] Failed to download disk 'VM-NAME.vmdk'. Reconnectable protocol device was closed.Failed to upload Disk. Skipped arguments: [VM-NAME.vmdk] Agent failed to process method {DataTransfert.SyncDisk}

Answer from support was just Check files with Veeam.Validator -> they are corrupt -> create new active full.

I cannot imagine, that its just 'bad-luck' that 6 of 7 just showed one of these two errors! I need to know if its a config error in Veeam or not (if not, we could start looking for problems with connection or storage itself)

There are 3 locations ->
- Location A hosting source backupfile
- Location B Veeam B&R Server
- Location C hosting NAS and proxy

Has anyone some experience with Veeam and iSCSI-Luns

Best regards
Freddy
veremin
Product Manager
Posts: 20400
Liked: 2298 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Corrupt Backupfiles after move to new repo

Post by veremin »

The provided errors identify data consistency issues and associated backup file corruptions . The most likely reason here is storage level problems which lay outside of backup server configuration: bit rot, connection problems, etc.

In other words none of possible backup server configurations should lead to the experienced behaviour, so it's better to put an eye on the hardware itself.

Thanks!
Post Reply

Who is online

Users browsing this forum: Spex and 72 guests