V-restore-user Decoding error (36)

Community Support Backups
1

I’m moving some sites from one server to another by creating a backup on the original Hestia box, scp’ing the tarball over to the new server and then using v-restore-user to create & restore the account on the new box.

This worked ok for the first few sites, although they were all quite small (<15MB tar files). I’m now trying with a larger site (> 6Gb tar) and keep getting these errors:

/*stdin*\ : Decoding error (36) : Restored data doesn't match checksum
tar: Child returned status 1
tar: Error is not recoverable: exiting now

I’ve tried creating a new backup tar and scp’ing that, but again v-restore-user fails.

Set up is Hestia 1.3.5 on both machines, Ubuntu 18.04 (x86_64) and both machines have 32GB RAM with 2TB disks on them.

Any ideas what I should try next?

Cheers,

Pete

2

An update - I switched to gzip compression and got these errors

tar: Skipping to next header
tar: A lone zero block at 979807
tar: Exiting with failure status due to previous errors

Bit of a worry…

3

Hmm that is odd. It would be the first possibility I would check.

Maybe check this:

I would try to split an backup in parts and see what part is causing the issues…

4

Is that something I can do via the Hestia webview, or do I need to get dirty in the CLI?

5

Ok, so I’ve tried changing the compression level in the Hestia backup config to 5 and then 1 on both zstd and gzip types, but still get the same error messages. One thing that seemed odd is that the file size for compression level 9 was the same as compression level 1. This seems odd.

6

An update from last night (managed to get to bed at 5.30am after much toying).

After various attempts creating a backup on the old server and scp’ing to the new, I did all the accounts, except the admin account which would always fail trying to unarchive the mail. Not surprising, as the mail on that account is mine and it’s huge (>22gb).

I solved this by making mail an exception in the Hestia backup on the old server, restoring that, then using ZIP to create an archive which I scp’d, then unzipped in place on the new server. I then did chown -R admin:mail on the unzipped folder to make sure the permissions were right.

However, the /home/admin/mail/domain.tld/new/ folder is steadily filling up, but not delivering mail. Doesn’t seem to be a problem with any of the other accounts I used the standard Hestia backup/restore functions on, so I’m guessing this ZIP/UNZIP method to get the mail folder across is missing a permission or config setting that the backup would have dealt with. Any pointers from the lovely experts on here?

It’s just my own mail account that’s effected, so I don’t have a client breathing down my neck, but would (obviously) really like to get it sorted so I can read my incoming mail :wink:

Thanks,

Pete