Support

Site Restoration

#14777 Invalid header extracting archive for restoration

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

Latest post by nicholas on Saturday, 26 January 2013 14:01 CST

user71395

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 2.5.8
PHP version: 5.3.14
MySQL version: Server version: 5.5.28-0ubuntu0.12.04.3
Host: localhost
Akeeba Backup version which took the backup: 3.6.12 (2013-01-04)
Kickstart version used to extract the backup: (unknown)

Description of my issue:

I have a production version on the server for a website and a development version on my computer (localhost). I am storing akeeba backups in an Amazon S3 bucket.  I made some changes to the live site and wanted to restore (i.e., overwrite) my local version with the live site database and files.  So I chose Import Achives from the Manage Backups screen.  The S3 archive showed up fine on the import screen:

graphic1_7fb08.jpg

After the import, the message "Import operation completed successfully" was displayed.  However, there were no entries in the backup screen:

graphic2_c34c3.jpg

And yet the actual backup files that came from S3 were sitting in the backup directory:

graphic3_5a37a.jpg

So I went back to Import Archives, but this time clicked "Scan for files" and selected the above archive.

Now the archive showed up in the backup/restore list.  However, when I did the restoration, I received this error:

graphic4_ebd3e.jpg

Despite this error, Akeeba proceeded with the restoration.  I did not see any way to abort this process.  It appears like the restoration worked correctly, but it is hard to tell without testing every single page in the site (not reasonable).  So is my development localhost potentially corrupted now due to the above error?  Is there a way to abort the restoration process in situations like this?  But, most importantly, is there a way to avoid the above error when importing an archive from S3 and restoring it?

 

nicholas
Akeeba Staff
Manager

When you are using the Import from S3 feature you only get to download the file from S3 to your server. It doesn't add it to the Manage Backups page. You will then need to use the Import Archives feature to import it to the Manage Backups page. Maybe I should had named the feature "Download from S3", the name is a little misleading.

Now, when you get an error message regarding an invalid file header the extraction stops. It seems that in your case (since about 89Mb had already been extracted) you ended up extracting the installation directory, including a complete backup of your database, and probably a few more files. The restoration doesn't proceed on its own accord, though. What happens is that Joomla! sees that there is a directory named "installation" and redirects you there. If you don't want to proceed with the restoration you simply have to remove the installation directory from your site.

As to whether your site is properly restored, I would guess not. Only the database portion of the backup was fully restored. The files weren't. I can't say if your site will work or not. There is no way to determine that other than visiting every page of the site (or at least a representative sample from each installed component).

As to the failed extraction, I'd suggest trying to download the backup archive from S3 to your local computer and extract it with Akeeba eXtract Wizard. If that still fails, your backup is genuinely corrupt. That's why I've added the last checkbox in Akeeba Backup 3.6.12's post-installation wizard, asking you to test your backups. An untested backup is as good as no backup at all. Despite our best intentions there are outside factors which can corrupt a backup, ranging from upload issues to files being corrupt while on S3 storage (remember that they give you a 99.999999999% durability for standard storage and 99.99% for reduced redundancy storage – corruption is unlikely but not impossible!), or even files which shrink while they are being backed up (log files being pruned are not uncommon and that's why we try our best not backing them up – but no solution is 100% perfect across all possible site configurations).

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!

user71395

Sure, renaming to "Download from S3" would help.  And, perhaps a note that if you want to manage the archive, to select "Scan for files" from the backup output directory.  Or, just add the S3 archive to the list of "Managed Backups." :)

So I downloaded the archive directly from AWS console, imported/scanned it into Akeeba and restored.  Everything worked correctly, so this tells me that the archive up on S3 must be okay.

So I deleted the archive from Akeeba and tried to import again from S3 using Akeeba's import option.  I think something is not quite right as it transfers it from S3.  When I click on the archive name in Akeeba, all I see is a spinning circle icon (I'm using Windows 7 for this/localhost -- server is running Ubuntu).  Then, the 100% progress bar appears after some time (presumably downloading):

graphic1_3d0db.jpg

But notice it is over 100% and... it just keeps going:

graphic2_bffe8.jpg

graphic3_0db40.jpg

until it has downloaded almost twice the size of the archive and get the success message:

graphic4_4ac64.jpg

This is what I downloaded directly from S3 via AWS console:

graphic5_6996d.jpg

This is what Akeeba downloaded from S3:

graphic6_423d6.jpg

So I guess this is why the import failed originally--the download process from S3 via Akeeba is not quite correct, or at least not what was expected?

But I have a accurate restore now on the local system, so that's good!  The ability to download from S3 directly in Akeeba is a really nice feature, though, and would rather do that download directly in Akeeba rather than go through the AWS console.

nicholas
Akeeba Staff
Manager

Thank you for the feedback. I will try to reproduce the issue and debug 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 Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!