Most likely some issue with the storage, in the past years we've been mostly seeing this with low end NAS featuring questionable performance optimizations. For example, the some storage will not handle FLUSH command correctly, returning success before the data hits the disks to achieve better performance numbers. Or, as simple as storage not writing some other data instead of the data we asked it to write due to faulty hardware (in 6 years and with 80'000+ customers, we've seen it all by now). It is very important that the storage does not "cheat" us.
Veeam backup file format includes two identical records of storage metadata for redundancy, and they are never updated at the same time, for at least one to remain "good" in case of a crash, or data corruption occurring during the file update.
So, it is simply impossible to break both metadata instances when:
1) Storage writes the data we asked it to write (not the case with faulty RAID controllers)
2) Storage medium stores the data correctly (not the case with silent corruptions issues aka bit rot)
3) Properly processes FLUSH command. The latter is a synchronous call for us, meaning we issue FLUSH command and wait for the data to hit the disks before moving on. If storage returns success but flush does not really happen, and we start updating another instance of metadata while first one is unsaved, and this is one way to run into the said issue.
In human language, the issues look like:
1) We ask storage to write "MOM", but it writes "DAD" instead and returns success.
2) We ask storage to write "MOM", and it writes "MOM" and returns success, but if you try to read the data block, you will get "MAM".
3) We ask storage to commit the write of "MOM" to disks, and it returns success but does not actually write data to disks, keeping it in buffer for a short period of time for performance optimization purposes.
Answering your question, we can only judge on these reported successes, so we mark the job as successful. This is why, it is very important to use SureBackup to verify that what was written into the backup file is what we asked, especially once you get this error at least once and your backup storage becomes a suspect.