zipping public_html results in missing originally contained files

[skrl]

I am trying to create a .zip file as a means of a manual backup of all of my public_html directory, after repeatedly failing to create a backup through my wordpress installation's environment. I have ordered 3 or 4 .zip files and 2 .tar.gz ones. Every time I order a .zip file, I end up with a text/x-generic file instead with a title pattern like zi6vWuLM with contents like:

Archive:  zi6vWuLM
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of zi6vWuLM or
        zi6vWuLM.zip, and cannot find zi6vWuLM.ZIP, period.

I've already searched online, but only managed to find content regarding unzipping files. I am not sure how they are really related, as in my case no .zip file is ever created.

When I order a .tar.gz file, a .tar.gz file is created, but when I copy and extract that one on a new host, to test it's not corrupted, it appears that random folders and files are missing.

Where should I look to troubleshoot this? It seems like I am unable to create a backup of my files. Any help is highly appreciated.

 

[cPRex]

Hey there! I'm guess the issue is with the "random folders and files" missing when you try to extrac the tar.gz. Are these always different files? Is everything in your user account owned by the cPanel username? If not, it will fail to include that, unless you are running these commands as the root user.

 

[skrl]

Hi, and thank you for your clarification requests. I believe the random folders and files missing result depends to the compression stage rather.

Just for the sake of verifying that is indeed what is happening, I created three consecutive .tar files. I thought I should give .tar a go also, after not having much success with .zip or .tar.gz files. With .tar, also, I noticed that all three files I created were of completely different file sizes. Specifically the first one was 452,4 MiB, then the second one was 1,3 GiB, and the third one was 182,5 MiB. I did not even bother to run them through the diff command, as it clearly appears seems like all three are including different files, despite explicitly selecting all the contenets of the public_html directory before ordering the compression.

Please kindly note that I am accessing the cPanel with the root user; the one that has a sheriff star on his chest in user manager.

 

[cPRex]

That's definitely odd, as I would expect those all to be the same. If you have root access to the entire server, I'd recommend submitting a ticket with our team so we can look into that behavior. If you only have cPanel access, you'd want to speak to your hosting provider or datacenter to have them check the machine for disk issues.

 

[skrl]

Unfortunately I don't have root access to the entire server. I will contact my hosting provider on your suggestion. Just to be clear, are you suspecting disk issues or low storage issues? The current quota limit is 5,000 MB of which 3,234.25 MB is being used, according to disk usage tool.

 

[cPRex]

I was thinking more along the lines of physical disk issues, and not quota problems - something keeping things from being written properly, or maybe even server load causing the process to stall.

 

[skrl]

It seems to have been a temporary error.

I just checked back today, and after selecting all and compressing twice (.zip), two exact copies of the public_html directory were created. Prior to my retries I also downloaded everything via FTP and then deleted unnecessary items which freed up an extra 1 GB of storage space. After downloading one of the two .zip files as a means of a manual backup, I also attempted to create a backup via the plugin inside of WP, and that worked like it was anticipated as well. I'll keep an eye on this in the future, but hopefully it is solved. I'll let the hosting provider know just in case anyway, or just for the record.

Thank you once again for the effort and replies, and for the promptness of both.

 

[cPRex]

I'd definitely let the provider know - at least that way if it happens again you can have a record of it.

I'm glad things are working well now, though!

 

[skrl]

I did do it just after I posted my last reply here; I let them know of all the steps I followed in the process, of what worked, and what didn't.

Thank you once again!