Can't unpack example.com data tarball

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?

  1. no, local backup
  2. 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!

[email protected]:~# 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.

[email protected]:~# ./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.

[email protected]:/home/backup# tar -xzpf domain_data.gz
[email protected]:/home/backup#

What problem?: Can’t unpack example.com data tarball

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 /backup to 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…

[email protected]:~# 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.

[email protected]:~# 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
[email protected]:~# 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
[email protected]:~#
[email protected]:~# 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
[email protected]:~# 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 :wink:

1 Like