Support

When you say "cpanel backup" you mean that you used cPanel instead of Akeeba Backup?

Okay. I am trying to understand the logic behind this ticket. You certainly realise that I have not written cPanel's backup feature. What you may not know is that I wrote the earliest versions of my backup software back in 2004 exactly because I was not satisfied with cPanel moving sites between hosts. These scripts became JoomlaPack in October 2006, which evolved to Akeeba Backup in February 2010. That's right, Akeeba Backup was originally written as a solution to my site transfer problem. 

With that in mind, why are you asking me for support about cPanel? I can't possibly know how it works and why it messes up. I don't have its source code. I am not its developer. Files are files. If cPanel treats some files differently than other files that's a cPanel issue, not mine. I would also posit that if you have found some files are not being copied, you cannot trust that site transfer process. Which other files were not copied, but you have no idea about it just yet?

The one thing I can tell you is that, indeed, the second problem happens because of the first problem. You have missing files, therefore the backup check plugin in the quickicon group is not working properly. Joomla! claims Akeeba Backup is installed and enabled, therefore the quickicon plugin tries to go ahead and load itself, but since the actual files of Akeeba Backup are missing the initialisation fails.

To me, the solution here would be obvious and fairly simple.

Take a backup of the original site. Restore it on top of the non-functional site. That's why you have Akeeba Backup to begin with.

so could there be something about administrator/components/com_akeebabackup (and the other missing folders, whatever they are) that would cause them not to be included in the backup?

I was trying to be polite, but I don't think you get it.

As per our Terms of Service, we can only provide support for our software. Everything else is outside the scope of our support. Since your request is about third party software I am going to close this issue without any further replies.

one question i have is : do i need to worry about the restoration script that is in the jpa file?  or can i just run the 'installer' and it will just do what is needed.?  and will not affect the production files from which the backup was taken?

When you extract a backup you overwrite the same-named files on the site you are restoring to, and you replace the database tables with those in the backup on the database of the site you are restoring to. Just make sure you use a different database for the restored site.

You sent me the following message through our contact form which I am including here for completeness:

i think it would be worthwhile adding this to the ticket, but i can't since it is closed:

in case it helps another akeeba backup customer, here is an update.

our hosting provider has taken it upon themselves to exclude some folders whose name contains the string 'backup', eg administrator/components/com_akeebabackup, from the cpanel backup. this is not documented.

i am astonished, i hope this isn't standard industry practice.

the folders are of course in the akeeba site backup file.

This is what I was trying to tell you. The problem is external to our software. Anything that does not happen as a result of executing our code is by definition not caused by the software.

Now that we have established it's a problem with the host, let me comment about whether it's common. Thankfully, it is NOT common – but we've seen things like that, and even worse. I'll give you a taste. More than a decade ago we had to publish this announcement: https://www.akeeba.com/news/1536-new-threat-hosts-delete-files-without-asking.html Crazy, isn't it?

In the end of the day, your and your host's business goals do not align. They need to minimise storage and bandwidth requirements. Your want to maximise resilience, which requires storage and bandwidth. This is why I've always been saying, even before writing JoomlaPack (Akeeba Backup's precursor) that you cannot trust your host to take backups for you. Now you understand why with first-hand experience.

My advice is simple. Take your own backups, always store them off-site, and test them regularly. You should always apply "trust, but verify". Don't trust that your host won't delete your files; take backups with Akeeba Backup. Don't trust that me and Davide didn't screw something up in Akeeba Backup; test your backups.