I have had a case open Case #07148096 on this issue. So far I have had no useful suggestions, nor does this seem to be a known issue. Around mid to late January I updated our Veeam B&R environment from 12 to 12.1, and also had our Linux sysadmin reboot the Linux hardened repos to apply kernel updates.
It seems that since then, Veeam jobs will end in a failure status when attempting to apply the 42 restore point retention policy, because the oldest vbk and vib files in the backup chain are still immutable. This means that for some reason the 14 most recent backups immutable policy is not being enforced when it comes to *removing* the immutability attribute.
I have tried starting new backup chains w/ new fulls on different repositories, but the issue persists across all repositories. I have had to work with the sysadmin to get root access to manually remove immutability from older files using chattr -i, so that Veeam can apply some retention policies and our repo capacities are under control.
Does this problem sound familiar to anyone? I don't even know where the breakage has happened between the VBR server issuing the info on immutable policies, and the local lock files/metadata that is supposed to be tracking immutability expirations.
According to this white paper on pg 17-19:
https://contenthub.gmevents.ae/wp-conte ... ackups.pdf
the Veeam service which sets and unsets extended attributes veeamimmureposvsc runs as root. Presumably that service is operational in terms of having root access, since it can clearly set the immutable attribute on newly created files. But something is preventing it from removing the immutable attribute on older files. Or it is not properly reading the lock and file metadata to get updated info on immutability expiration?
It seems that since then, Veeam jobs will end in a failure status when attempting to apply the 42 restore point retention policy, because the oldest vbk and vib files in the backup chain are still immutable. This means that for some reason the 14 most recent backups immutable policy is not being enforced when it comes to *removing* the immutability attribute.
I have tried starting new backup chains w/ new fulls on different repositories, but the issue persists across all repositories. I have had to work with the sysadmin to get root access to manually remove immutability from older files using chattr -i, so that Veeam can apply some retention policies and our repo capacities are under control.
Does this problem sound familiar to anyone? I don't even know where the breakage has happened between the VBR server issuing the info on immutable policies, and the local lock files/metadata that is supposed to be tracking immutability expirations.
According to this white paper on pg 17-19:
https://contenthub.gmevents.ae/wp-conte ... ackups.pdf
the Veeam service which sets and unsets extended attributes veeamimmureposvsc runs as root. Presumably that service is operational in terms of having root access, since it can clearly set the immutable attribute on newly created files. But something is preventing it from removing the immutable attribute on older files. Or it is not properly reading the lock and file metadata to get updated info on immutability expiration?
Statistics: Posted by joebranca — Apr 01, 2024 8:30 pm
