Akeeba Backup for Joomla!

Saturday, 01 October 2011 09:15 CDT

flux3

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? yes lots of them
Have I searched the forum before posting? yes
Have I read the documentation before posting (which pages?)? Akeeba Backup (ALL), Kick start/Akeeba extract wizard.
Joomla! version: 1.7.0
PHP version: 5.3
MySQL version: 5.1
Host: www.ukhost4u.com
Akeeba Backup version: Akeeba Backup Professional 3.3.4 (2011-09-12

EXTREMELY IMPORTANT: Akeeba Backup log file attached.

Description of my issue:
I had trouble moving my site from a temporary domain to its fulltime home which i solved using Akeeba's site transfer wizard. Now when i create a backup it seems to go through just fine. The problem is when i try to restore it locally (xampp)i run kickstart(3.3.2) and immediately get the error..."Invalid header in archive file, part 0, offset 20554". I have tried downloading the file through linux Cpanel, with dreamweaver,through Filezilla (in binery mode) using these methods on both mac osx 10.6 and windows 7. Whatever i try seems to make no difference. I also tried a zip instead of .jpa but that wouldnt unpack and extract wizard(3.3) on windows 7 said invalid Archive format. This leads me to believe the problem lies in the server/joomla area but iv been know to be wrong once or twice.80) Sorry for the format of this post, every time i use a carriage return i get an oops page(chrome14.0). I have used Akeeba Backup and kick start a huge amount over the last year so im not a noob at the process but this has got me stumped and now iv spent nearly a day trying to sort it i need to call in the big guns Mr D... Hope you can help

Saturday, 01 October 2011 15:51 CDT

nicholas

Hi!

OK, let's try the scenic route. First, make sure you have a backup archive in JPA format, as it is far more stable than the ZIP format (especially if you have files over 1Mb).

Download that file to your local PC using FileZilla in Binary transfer mode. If you have a multi-part backup, download all of the part files (.jpa, .j01, .j02). Then, use Akeeba eXtract Wizard to extract it locally.

If this still fails, it could be because you are backing up your error_log files. These files change their size during backup and could cause a restoration issue. Use the Files and Directories Exclusion feature of Akeeba Backup to exclude the following:
error_log
administrator/error_log
If you have any other log files anywhere in your site, exclude them as well (a quick scan in your log file doesn't show anything like that). For good measure, also set the site to off-line and take a new backup. Then try using that new backup.

If all else fails, ping me again!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 01 October 2011 17:28 CDT

flux3

I always use jpa and Filezilla in Binary mode so we should be able to rule that out. I tried excluding the error_log file and actually thought this might work because i had already noticed that file seems bloated at 80+mb for a new site. After excluding it my jpa file went back to a sane 13mb but unfortunately i get exactly the same error message when running kickstart"Invalid header in archive file, part 0, offset 20554" even the offset is exactly the same each time.

any other stops along the scenic route?

Sunday, 02 October 2011 04:03 CDT

nicholas

There's one more thing to try. This offset points to a file from the integrated installer. This makes me think that something is terribly odd on the source site (maybe a broken installer package?). Try re-installing Akeeba Backup on that site.

If this doesn't work, go to the Configuration page and try selecting "None" as the embedded installer. If that archive extracts correctly, I can give you a ZIP file with the missing installer files so that you can perform the restoration.

If all of the above fail, just send me a PM with the following information:
- URL to the administrator section of the source site
- Super Admin username/password
- If possible, FTP connection information; I can do without it
- A link back to this thread so that I know why you're sending me the PM :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Sunday, 02 October 2011 07:26 CDT

nicholas

Thank you for your PM! Unfortunately, I have very bad news :( The problem is in your server. One of the core PHP functions -pack()- is not working properly. This means that PHP is completely incapable of writing the archive headers of any archive format. Since this is a grave issue with your hosting environment, I strongly recommend telling your host to recompile and reinstall PHP and restart Apache.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Sunday, 02 October 2011 08:35 CDT

flux3

hmmmm they did add some php functions to the blocked list recently that stopped loads of Joomla sites working and had to put them back in the allowed list. I wonder if this was left in the blocked list?

Now i had better check my other sites backups are OK on the same host.
Thank you for taking the time to look into it and i suppose on the bright side its good news, it's not Akeeba and it's not me that is to blame....80)

There is always a bright side once the storm blows over. (my new quote)

Sunday, 02 October 2011 08:40 CDT

nicholas

No, they're not blocked. If they were blocked we'd get a PHP Fatal Error, as PHP would "think" that the blocked functions are not defined. The problem is that pack() always returns NULL, even when the arguments passed are correct, e.g pack('V',27). This caused mayhem in the archive; all of the file headers were corrupt and, of course, extraction was outright impossible.

If you have a choice, I'd suggest migrating to a host who knows better what they're doing. Disabling half of the known universe to make a PHP setup "secure" is a strong indication that the server setup is insecure, there has been a major hacking incident lately and the host is panicking and doesn't know what to do. Well, at least that's what happens in 90% of those cases. The other 10% is attributed to plain old -and infinite, according to Einstein- human stupidity.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 03 October 2011 05:33 CDT

flux3

Thanks for the advice Nicholas, im looking at moving to Rochen. There seems to be a shortage of decent UK hosts.

I had to wait for my current host providers php guy to come in today and he has asked if Akeeba is compatible with php 5.3?

Monday, 03 October 2011 05:35 CDT

nicholas

Akeeba Backup is being developed and tested on PHP 5.3.8 so, yeah, it's not only PHP 5.3 compatible, it's designed for PHP 5.3. It is also routinely tested against a PHP 5.2.17 host to ensure that we don't accidentally break PHP 5.2 compatibility like what happened a few releases ago.

I only have good words to say about Rochen. If you move your site to them you won't regret it :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support