Corrupt files in Agent for Linux backup

[sg_sc]

I recently restored a Linux cloud VPS and I experience the issue that their are some corrupt files in the backup.
These files will have their original file size (for instance 25 KB) but they are just filled with the NULL character, the ^@ in VI or just all 00 in hex format.
The cloud VPS was running on Digitalocean (KVM virt) with CentOS 7 x64 and 1 disk with ext4 filesystem.
I was using Veeam Agent for Linux GA and backing up to a VBR 9.5 U1 on a ReFS disk over a OpenVPN tunnel with TAP interface.

The first file I found was a static config file of the OpenDKIM daemon on the system (KeyTable) which was the culprit of the malfunctioning of my outgoing mailfow.
The second file I found was a CSS file from a web application.
After that I went hunting for such files on the system:
- found a corrupt binary, it was "/usr/sbin/httpry". A simple "yum reinstall httpry" fixed that.
- found 3 corrupt php files and 2 corrupt xml files from the phoronix-test-suite. A simple "yum reinstall phoronix-test-suite" fixed those 5 files.
it goes on and I found corrupt files from nmap, webmin, alsa-firmware, php-tcpdf, some image files, ...

One could argue that the corrupt files existed on the cloud VPS, but I know for a fact that the web application was fine and after restore it was not showing properly because of the corrupt CSS file.
Anyone seen this behavior before?

[nielsengelen]

Haven't had this issue before. Could you open up a support case so they can investigate where something might have gone wrong resulting in this behavior.

[sg_sc]

To be sure I started a new VM in virtualbox and using the Veeam Recovery Media restored volume from backup from a month ago. After it finished, while still in the recovery media, I switched to console then mounted the disk and checked the specific CSS file. It was corrupt. So that seams to indicate that it's not a bug while restoring, but the file is corrupt in the backup.

[sg_sc]

I opened a case, but since it's the free version not sure how it will be handled.

[Mike Resseler]

For the free support. You will get support from us but not with an SLA. So it comes on a best effort basis for timing but we will handle your support case
Mike

[sg_sc]

Still working with support on this, providing info as they request it. Will update this topic if something is found.
case: 02103589

[Mike Resseler]

Thanks!

As I said it is a free solution support so they work when they have time available but as you can see, we are contacting you and working on it. Updating the topic further would be very much appreciated

[PTide]

Hi,

I'd like to clarify something:

Although our standard SLA does not apply to Free products, case priority can be escalated if needed. You case is exactly the one that had to be escalated, so I did - development team is already involved in the process.

Thank you

[sg_sc]

Update: Veeam support was able to reproduce this behavior and thus confirmed a bug in bitlooker component. Advice is to disable bitlooker until a new build is available.