Solved Error on restore! Decoding error (36) : Restored data doesn't match checksum only with .zst

Richard G

Verified User
Joined
Jul 6, 2008
Messages
13,771
Location
Maastricht
We are transferring accounts to a new server. I made backups via admin backup/transfer and are now restoring on the new server but it comes with errors on various accounts.

Unable to extract the directory 'backup' from the file /home/admin/admin_backups/user.admin.pietje.tar.zst as user pietje
/*stdin*\ : Decoding error (36) : Restored data doesn't match checksum
/bin/tar: Child returned status 1
/bin/tar: Error is not recoverable: exiting now

Got 2 or 3 others, in those cases its same error but user.conf like this:
Unable to extract backup/user.conf from /home/admin/admin_backups/user.admin.pietje.tar.zst

What is this and how can I fix this?

I could rsync the user.conf from the old server, but I don't know if that would be safe enough.
Edit: Nope, user.conf is not enough, all domains are missing from the restore.
 
Last edited:
So this issue was with big files (unpacked around 25 GB) and -only- with .zst compression.
I changed the configuration to use .tar.gz as backup method.

And now the restore went fine without any issue.

Is this a bug within DA and .zst or why is tar.gz working flawlessly and restore of .zst gives me these issues?
 
Hello Richard,

I guess the error "Restored data doesn't match checksum" is caused by the fact the file was either corrupted during the upload, or did not transfer in full.

And while I don't have a reply, I could still give you an idea on how to test it. You might find it out by extracting a ZST file in cli. Try and unpack the file, if you get an extracting error, it might give you a clue.


Is this a bug within DA and .zst or why is tar.gz working flawlessly and restore of .zst gives me these issues?
 
Hello Alex.

corrupted during the upload, or did not transfer in full.
At least for 2 accounts this was a fact as I discovered. The files were backed up and directly send via ftp and they were small. Too small.

The 3rd file was the correct value. Unfortunately since we got everything good via tar.gz backup I didn't thought of unpacking and deleted the .zst file since that backup did not restore anyway. So unfortunately can't try to unpack anymore.

Another bigger file did work however. So corrupted during upload is a possibility indeed. The original server had one disk in the raid 1 system which was starting to go bad.

I will put it to solved then as I was so dumb to delete the file without testing afterwards. ;)

Thank you.
 
Back
Top