zbackup restore sometimes fails with "Check failed: lzma_code error: 9 At /builddir/build/BUILD/zbackup-1.4.4/compression.cc:58"

[Sebastian Schlüter]

Hello,

when testing my encrypted repo's backups via

for x in /zbackup/**/*.zbackup
do
  zbackup --cache-size 1024mb --password-file ~/.my_backup_password restore $x > /dev/null
done

I sometimes get

Check failed: lzma_code error: 9
At /builddir/build/BUILD/zbackup-1.4.4/compression.cc:58

I am puzzled as to why this happens.

Here are my finding so far:

1) If I stubbornly and immediately run the test again, it surprisingly runs fine.

This lead me to think that the on-disk-data is probably fine. I have checked this several times including full system reboots in between to rule out file system cache effects. Then probably my RAM is faulty or there is some random bit flip happening. I am running this on a cheap laptop with no ECC RAM. On the other hand, the system otherwise runs fine and I have not experienced any weird problems like this before.


2) As all backups consist of dar archives, I can also verify my backups via

for x in /zbackup/**/*.zbackup
do
  zbackup --cache-size 1024mb --password-file ~/.my_backup_password restore $x | dar -0 -t -
done

dar then tells me which file inside the archive the error occurs. It is the exact same file every time the check fails.

This leads me to think that this is probably not a random RAM bit flip because it would kick in randomly and would not affect the same file inside the same dar archive, especially not since the whole system has been rebootet several times.

I am running Fedora 23 in a virtual maschine via VMware Workstation 12 Player running on Windows 10.

If it was a bug in Vmware player then it would probably occur every time I run the test, wouldn't it?

The linux kernel logs no error messages via dmesg. Vmware player also logs no error message. And windows 10 also logs no error messages.

zbackup has been installed via Fedora 23 standard repository.

Could there exist some weird timing issue or race condition in compression.cc that could lead to the situation that sometimes the zbackup restore is fine and sometimes it fails?



Thanks a lot for your ideas and best regards,
Sebastian

[Sebastian Schlüter]

Never mind, it's a hardware problem. memtest86+ does not detect any errors, but still I even get the following sometimes:

[sebastian@localhost ~]$ dar -c - -R . | dar -0 -t -
...
ERR <ROOT>/path/to/file : CRC error: data corruption.
...
 56257 item(s) treated
 1 item(s) with error
 0 item(s) ignored (excluded by filters)
 --------------------------------------------
 Total number of items considered: 56258
 --------------------------------------------
Final memory cleanup...
Some files are corrupted in the archive and it will not be possible to restore them


So, my issue has nothing to do with zbackup.