Hello!
Why problem?: Can’t unpack example.com data tarball
Help please.
sorry, with that kind of information we can’t offer any help at all. please be much more descriptive.
what exactly are you trying to do that make this message appear and where do you see this.
what does your system config look like and which os and what Hestia components do you have installed.
how is your error message related to Hestia at all?
Sorry
Debian 9 64Bit
Hestia: v1.2.1
I tried website recovery but unfortunately sends this in an email. (customer account)
Did you import a Hestia backup?
On what version did you create the backup?
- no, local backup
- v…2.1 (today)
today:
apple-1.2020-08-10_05-16-18.tar
okay, so you try to restore from a backup that you have locally on your server and that has been created by the cronjob today morning?
I am afraid the only thing you can do is try to manually unpack it first and see in more detail what tar is complaining about. inside the main archive you will find multiple other archives, that hold the domain data, mail data and mysql data seperately. seems there is an issue with unpacking one of em?
can you check how much space you have left on your disk? maybe you ran out of space and therefore the restore process is not able to unpack all stuff properly…
you will need at least twice the space of the domain data folder to be on the safe side (unpack the tgz first and then the real data from that…)
1 Like
okay, so you try to restore from a backup that you have locally on your server and that has been created by the cronjob today morning? -yes!
root@server1hu:~# df -h
Fájlrendszer Méret Fogl. Szab. Fo.% Csatol. pont
udev 24G 0 24G 0% /dev
tmpfs 4,8G 498M 4,3G 11% /run
/dev/sda3 106G 9,2G 91G 10% /
tmpfs 24G 0 24G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 24G 0 24G 0% /sys/fs/cgroup
/dev/sda1 487M 132K 486M 1% /boot/efi
/dev/md0 938G 222G 670G 25% /home
tmpfs 4,8G 0 4,8G 0% /run/user/1022
tmpfs 4,8G 0 4,8G 0% /run/user/0
My backup folder /home/backup
2x1TB raid 1 new SSD.
root@server1hu:~# ./HDSentinel
Hard Disk Sentinel for LINUX console 0.18c.8675 © 2019 [email protected]
Start with -r [reportfile] to save data to report, -h for help
Examining hard disk configuration …
HDD Device 0: /dev/nvme0
HDD Model ID : INTEL SSDPEKNW010T8
HDD Serial No: BTNH93600Q8L1P0B
HDD Revision : 002C
HDD Size : 976762 MB
Interface : NVMe
Temperature : 36 °C
Highest Temp.: 36 °C
Health : 100 %
Performance : 100 %
Power on time: 52 days, 23 hours
Est. lifetime: more than 1000 days
Total written: 4.51 TB
The status of the solid state disk is PERFECT. Problematic or weak sectors were not found.
The health is determined by SSD specific S.M.A.R.T. attribute(s): Available Spare (Percent), Percentage Used
No actions needed.
HDD Device 1: /dev/nvme1
HDD Model ID : INTEL SSDPEKNW010T8
HDD Serial No: BTNH93600TZV1P0B
HDD Revision : 002C
HDD Size : 976762 MB
Interface : NVMe
Temperature : 35 °C
Highest Temp.: 35 °C
Health : 100 %
Performance : 100 %
Power on time: 52 days, 23 hours
Est. lifetime: more than 1000 days
Total written: 5.39 TB
The status of the solid state disk is PERFECT. Problematic or weak sectors were not found.
The health is determined by SSD specific S.M.A.R.T. attribute(s): Available Spare (Percent), Percentage Used
No actions needed.
HDD Device 2: /dev/sda
HDD Model ID : WDC WDS120G2G0A-00JH30
HDD Serial No: 19426A459203
HDD Revision : UE220400
HDD Size : 114473 MB
Interface : S-ATA Gen3, 6 Gbps
Temperature : 36 °C
Highest Temp.: 43 °C
Health : 100 %
Performance : 100 %
Power on time: 52 days, 8 hours
Est. lifetime: more than 1000 days
Total written: 3.09 TB
The status of the solid state disk is PERFECT. Problematic or weak sectors were not found.
The health is determined by SSD specific S.M.A.R.T. attribute(s): #230 Media Wearout Indicator
No actions needed.
tar -xvf alma-1.2020-08-10_05-16-18.tar -> sucessfull
thanks, looks like you indeed should have enough diskspace at hand.
this only unpacks the highest level (good if it’s working though), the one that fails according to your error message will be deeper inside that unpacked folder structure. you can look up the correct tar.gz somewhere in that and check if it’s extractable as well, we use tar -xzpf for that.
the domain_data.tar.gz is also unpacked with user permissions, so maybe there is something off with those permissions on the old homedir/user account already - which would lead to the restore process not being able to extract into the webdomains folder?
maybe why ever you need to rollback to a backup in first place, something more is borked with that account, so you probably want to remove that user from hestia completly first and then restore, that should create all directories and permission fresh?
/home/backup# tar -xzpf apple-1.2020-08-10_05-16-18.tar
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
please read again. I was talking about archives which are in that tar. so after unpacking the tar with plain tar as you already did before, look into that folder and search for the domain_data.tar.gz in question within.
root@server1hu:/home/backup# tar -xzpf domain_data.gz
root@server1hu:/home/backup#
that problem!: Can’t unpack example.com data tarball
seriously… as said before, without any additional informations, we can’t help you out here. this is something that you need to solve with your own sys-admin skills. meaning, run manually through the steps, that the restore script would do, it’s all in there.
we can only fix issues or bugs with a proper file report, that allows us to reproduce the problem. so we need to know what you might have done before (and maybe that includes the reason, why you even need to restore from backups in the first place)
I’ve pointed into that direction before… if you are able to unpack the archives manually, most likely there is something wrong with the user permissions of the target folder where the files should go into. did you play around with chmod and chown on that users folders for some unknown reason?
you can either check and fix these, restore from the backup manually or remove the user account completely and have it recreated through the restore process.
owner and group: root
premmisions: 700
These are on it by default … do I have to raise the license rights? It needs to be restored because the page has fallen apart after updating wordpress plugin.
I don’t know what you mean by that.
- is your backup folder by any chance a mounted nfs drive or something external like that?
- could you post an
ls -lah /backupto see the owner/permissions on the backup-files? - also see the other thread about the same issue that just came up, if you could post the same log-file information from your side would be helpful as well…
root@server1hu:~# ls -lah /backup
lrwxrwxrwx 1 root root 12 júl 10 22:54 /backup -> /home/backup
-rw-r----- 1 admin apple-1 111M aug 13 05:13 apple-1.2020-08-13_05-13-09.tar
thanks, this is as it should be, so not related to the problem from the other thread.
I just noticed and missed that post before… 700 on the home folder is wrong and definitely not the default for the home folder or the folder below that.
inside /home
drwxr-xr-x+ 11 root root 4,0K Jul 14 11:50 testuser
inside /home/testuser
drwxr-xr-x 4 root root 4096 Jul 14 11:50 conf
drwxr-x--x 2 root root 4096 Jul 14 11:50 mail
drwxrwx--x 2 testuser testuser 4096 Jul 14 11:50 tmp
drwxr-x--x 2 testuser testuser 4096 Jul 14 11:50 web
inside /home/testuser/web
drwxr-x--x 9 testuser testuser 4096 Aug 13 19:41 testdomain.com
inside /home/user/web/testdomain.com
drwxr-x--x 2 testuser testuser 4096 Aug 13 19:41 cgi-bin
drwxr-x--x 2 testuser testuser 4096 Aug 13 19:41 document_errors
dr-xr-x--x 2 testuser testuser 4096 Aug 13 19:41 logs
drwxr-x--x 2 testuser testuser 4096 Aug 13 19:41 private
drwxr-x--x 2 testuser www-data 4096 Aug 13 19:41 public_html
drwxr-x--x 2 testuser www-data 4096 Aug 13 19:41 public_shtml
dr-xr-x--x 2 testuser testuser 4096 Aug 13 19:41 stats
as you can see, all folders have always world executable rights all the way down - so most likely the restore process is not able to access that folder. simple. why or however you changed that (accidentically?) you might want to reverse it or remove the complete user and have it recreated so the permission get corrected.
root@server1hu:~# ls -lah /home
összesen 96K
drwxr-xr-x 24 root root 4,0K aug 13 11:52 .
drwxrwxrwx 24 root root 4,0K aug 3 12:29 ..
drwxr-xr-x+ 11 root root 4,0K aug 10 18:02 apple-1
drwx------ 3 root root 4,0K aug 13 05:43 backup
root@server1hu:~# ls -lah /home/apple-1/
összesen 60K
drwxr-xr-x+ 11 root root 4,0K aug 10 18:02 .
drwxr-xr-x 24 root root 4,0K aug 13 11:52 ..
-rw-r--r-- 1 root root 23 aug 10 18:02 .bash_aliases
-rw-r--r-- 1 apple-1 apple-1 220 máj 15 2017 .bash_logout
-rw-r--r-- 1 apple-1 apple-1 3,5K máj 15 2017 .bashrc
drwxr-xr-x 2 apple-1 apple-1 4,0K júl 11 01:57 .cache
drwxr-xr-x 2 apple-1 apple-1 4,0K júl 11 01:57 .composer
drwxr-xr-x 5 root root 4,0K júl 11 01:57 conf
drwxr-xr-x 2 apple-1 apple-1 4,0K júl 11 01:57 .config
drwxr-xr-x 2 apple-1 apple-1 4,0K júl 11 01:57 .local
drwxr-x--x 3 root root 4,0K júl 11 01:57 mail
-rw-r--r-- 1 apple-1 apple-1 675 máj 15 2017 .profile
drwxr-xr-x 2 apple-1 apple-1 4,0K júl 11 01:57 .ssh
drwxrwx--x 2 apple-1 apple-1 4,0K aug 10 21:52 tmp
drwxr-x--x 3 apple-1 apple-1 4,0K júl 11 01:57 web
root@server1hu:~#
root@server1hu:~# ls -lah /home/apple-1/web
összesen 12K
drwxr-x--x 3 applet-1 apple-1 4,0K júl 11 01:57 .
drwxr-xr-x+ 11 root root 4,0K aug 10 18:02 ..
dr-xr-x--x 9 apple-1 apple-1 4,0K aug 12 04:13 apple.hu
root@server1hu:~# ls -lah /home/apple-1/web/apple.hu
összesen 36K
dr-xr-x--x 9 apple-1 apple-1 4,0K aug 12 04:13 .
drwxr-x--x 3 apple-1 apple-1 4,0K júl 11 01:57 ..
drwxr-x--x 2 apple-1 apple-1 4,0K nov 23 2019 cgi-bin
drwxr-x--x 2 apple-1 apple-1 4,0K aug 12 04:13 document_errors
dr-xr-x--x 2 apple-1 apple-1 4,0K aug 12 04:13 logs
drwxr-x--x 6 apple-1 apple-1 4,0K júl 19 01:22 private
drwxr-x--x 5 apple-1 www-data 4,0K aug 13 19:06 public_html
drwxr-x--x 2 apple-1 www-data 4,0K nov 23 2019 public_shtml
-rw-r--r-- 1 apple-1 apple-1 0 jún 8 20:55 restore_errors.log
dr-xr-x--x 2 apple-1 apple-1 4,0K nov 23 2019 stats
I have already manually restored their website, I just want to solve the problem. This is a sharp side.
this is the problem then. I too have created a folder in /home for backups and linked it to /backup
works good but it needs to have 755. I am repeating myself. your permissions are off, hence your restore can’t work. I am done here 
1 Like
I had the same problem. Can’t unpack data tarball.
Issue was the /backup/ folder permission was 755. It supposed to be 777
But the actual scenario found is, the backup/folder permission automatically changing back to 0755 on after a single domain restore. I think there is something on the restore script is changing this permissions to 0755.
Hope the Deve team will look on this.
The permission can be set as
- Change permission to 0755
- Start backup/restore
- Change back to 0755
So next time while we trigger restore, it will do accordingly.