Support

Site Restoration

#22145 no longer able to restore any backups

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 Wednesday, 25 February 2015 09:55 CST

kmeyer9999
I've used Akeeba Backup for several years without problems, about a week ago I started encountering errors on restore. The problems started soon after (possibly immediately after, I'm not certain) upgrading from Backup 3.11.4 to Backup 4.1.2.

I'm trying to port my site from preview.kurtmeyer.com to test2.kurtmeyer.com, am using FileManager to move the backup to the test2 folder. Or, if downloading, I am using FireFTP in Binary mode.

On running Kickstart, I get errors such as "Invalid header in archive file, part 0, offset xxxx", but when I re-start Kickstart the offset changes, the status bar shows a different file, and every now and then it simply works. I've also had problems where it restores the files, then gives errors during the database restore, again if I restart the db restoration the location of the error changes and finally succeeds after several restarts, sorry I can't give you exact errors for this as it hasn't gotten that far recently.

I've excluded log files from the backup, and have searched the forums for possible solutions.

As an example, here is the error I got the first time I tried to restore a fresh backup today:
Invalid header in archive file, part 0, offset 13167160
and the next time it was:
Invalid header in archive file, part 0, offset 12583214
and the third time it was:
Invalid header in archive file, part 0, offset 16457848

I'm attaching the log file from the backup creation, and here are the lines from error_log in the target folder during a number of restoration attempts today:
[25-Feb-2015 00:14:02 UTC] PHP Warning: require_once(/home/kurtmeye/public_html/test2/includes/defines.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /home/kurtmeye/public_html/test2/index.php on line 28
[25-Feb-2015 00:14:02 UTC] PHP Fatal error: require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/home/kurtmeye/public_html/test2/includes/defines.php' (include_path='.:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php') in /home/kurtmeye/public_html/test2/index.php on line 28
[25-Feb-2015 00:15:06 UTC] PHP Warning: gzinflate() [<a href='function.gzinflate'>function.gzinflate</a>]: data error in /home/kurtmeye/public_html/test2/kickstart.php on line 4864
[25-Feb-2015 00:29:02 UTC] PHP Warning: require_once(/home/kurtmeye/public_html/test2/includes/defines.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /home/kurtmeye/public_html/test2/index.php on line 28
[25-Feb-2015 00:29:02 UTC] PHP Fatal error: require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/home/kurtmeye/public_html/test2/includes/defines.php' (include_path='.:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php') in /home/kurtmeye/public_html/test2/index.php on line 28
[25-Feb-2015 00:37:38 UTC] PHP Warning: gzinflate() [<a href='function.gzinflate'>function.gzinflate</a>]: data error in /home/kurtmeye/public_html/test2/kickstart.php on line 4864
[25-Feb-2015 00:38:19 UTC] PHP Warning: require_once(/home/kurtmeye/public_html/test2/includes/defines.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /home/kurtmeye/public_html/test2/index.php on line 28
[25-Feb-2015 00:38:19 UTC] PHP Fatal error: require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/home/kurtmeye/public_html/test2/includes/defines.php' (include_path='.:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php') in /home/kurtmeye/public_html/test2/index.php on line 28
[25-Feb-2015 01:02:50 UTC] PHP Warning: gzinflate() [<a href='function.gzinflate'>function.gzinflate</a>]: data error in /home/kurtmeye/public_html/test2/kickstart.php on line 4864
[25-Feb-2015 01:04:12 UTC] PHP Warning: gzinflate() [<a href='function.gzinflate'>function.gzinflate</a>]: data error in /home/kurtmeye/public_html/test2/kickstart.php on line 4864

I normally use FireFox but for this last attempt have done everything on Google Chrome.

I've also tried restoring the backup locally with similarly random offset errors. And using eXtract Wizard locally I get Warning: Invalid Archive Format, but this always stops with the same file (a jpg) showing in the status bar.

If you can help me figure out why I can no longer create a viable backup, I'd really appreciate it. Thanks for your support.

nicholas
Akeeba Staff
Manager
Can you please paste the path to the .jpg file shown when the restoration stops? I have a suspicion of what could be going on but I'd like to be certain instead of possibly sending you on a witch hunt.

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!

kmeyer9999
Sure, when eXtract Wizard stops for this backup it is always showing the following in the status area:
images/stories/virtuemart/product/resized/8-pt/1015-14-02_0x220.jpg
I see the file is created, but it is empty.

When I run kickstart, the path that is showing changes, just like the offset changes. I just ran it twice, the first time:
Invalid header in archive file, part 0, offset 11279786
/home/kurtmeye/public_html/test2/images/stories/virtuemart/category/3010h.jpg
The second time:
Invalid header in archive file, part 0, offset 12648347
/home/kurtmeye/public_html/test2/images/stories/virtuemart/product/2330/2330-14-04.jpg

Possibly a problem with Virtuemart? (version 3.0.4). I was making many changes in VM at the same time that I upgraded Akeeba Backup. I am also using CSVI 5.20 Pro to populate my VM categories, products, shipping methods, and users, and installed CSVI for the first time around the time these problems started, though I was able to succesfully port my site from localhost to my subdomains for online testing several times before becoming stumped by this problem.

I have been ftp'ing the images themselves, and letting VM handle re-sizing. Yikes, after writing that sentence it occurred to me to look at that jpg and it turns out the file is there with size "0KB". I deleted it, reran the backup, and...the first time I ran it Chrome crashed immediately, the window just disappeared. Re-running it, Kickstart quickly jumps to a completed status bar and just hangs. Running eXtract Wizard on this new backup hangs at
plugins/vmc
I'm attaching the error_log from the restore attempt on the server.

Thanks for helping me with this.

nicholas
Akeeba Staff
Manager
OK, we're getting somewhere. Can you please try setting your site off-line through Global Configuration before backing up and make sure that you have no CRON jobs running while backing up? The errors you describe are consistent with files whose size changes while they are being backed up.

Also, before the restoration can you please try clearing any cookies you have for the domain name you are restoring to?

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!

nicholas
Akeeba Staff
Manager
And one more thing. Please make sure that you're using Akeeba Kickstart 4.0.0 for the restoration.

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!

kmeyer9999
That seems to have done the trick, thank you so much! I wonder what it is that is changing size while running the backup, is there any way to track that down? Thanks again!

nicholas
Akeeba Staff
Manager
I suppose it's VirtueMart. You upload a lot of image files via FTP. How would VM know that you did and be able to resize them? Remember that Joomla! extensions only run when you are accessing a page on the site. I just gave the answer away: when you or a search engine is accessing a VM page it sees the files uploaded via FTP and starts creating the resized images. It does a few images, then stops to prevent a server timeout.

This process happens in parallel with the backup. This means that at some point Akeeba Backup sees file X with a size Y and starts backing it up. However, this file is now overwritten by VM and the new size is Z. If Z is different than Y then this file's data in the backup archive are inconsistent with the file header (a chunk of data describing the file in the backup archive), therefore the archive is corrupt.

By putting your site off-line you stop the parallel processing, allowing the backup to conclude successfully. It goes without saying that once VM processes all files you have uploaded there will be no need to put your site off-line any more before taking a backup. And yes, as you suspected the best thing to do is upload the images though VirtueMart, having it resize them at that time and preventing this sort of parallel processing which causes backup inconsistencies.

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!