Akeeba Backup for Joomla!

Wednesday, 27 May 2015 05:57 CDT

leggett26

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue: As per ticket #22639 the ANGIE restoration script still fires up after the site has been built through cmd line(UNITE). The site is complete but we still get ANGIE pop up even after we unchecked the embedded restoration script option. Would it help if we send you a JPA file that you can try? How do we complete the install without the ANGIE firing up again?

Kind regards

Ian

Wednesday, 27 May 2015 07:27 CDT

nicholas

As I explained, every single time I've seen this issue it's because there is a code cache on the server. The code cache is enabled by default with PHP 5.5 and later. You need to reset the code cache after every code change on your site including:

Site restoration
Joomla! update / upgrade
Extension installation
Extension update / upgrade
Every time an extension generates an executable .php file. This not a recommended practice but several extensions (e.g. Zoo) and templates (e.g. everything based on RocketTheme's Gantry with GZip compression enabled) do it anyway.

The effect of the code cache is that the PHP executable does NOT look at the filesystem to see if the files have changed. Instead it "remembers" the last time it looked. When you are restoring your site OR installing Joomla! from scratch there is a directory called "installation" which contains the site restoration script (ANGIE) or the Joomla! installation script. After the restoration/installation is complete this directory is deleted. If the code cache kicks in the PHP on your server doesn't know it's removed and runs it anyway, from the copy cached in memory.

Since you're your own host you can simply restart your web server daemon. If you're using PHP-FPM you need to restart PHP-FPM instead.

Please keep in mind that your server is doing what you told it to do, not what you'd want it to do. For the record, this thing DID stump me last year. I spent an hour trying to figure out what the heck I'm doing wrong and my code changes, confirmed written on the disk, didn't apply... and then it dawned on me. Code cache. Restarted Apache, problem gone until the next change. I finally disabled code cache on my dev server and only enabled it on my test servers – and I do remember to reset the cache every time I test install new versions of our software for testing purposes.

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!

Wednesday, 27 May 2015 08:54 CDT

leggett26

Have you tried using the opcache.blacklist_filename setting to specify that the akeeba backup files should never be cached? Does this work?

This may avoid us having to switch the settings back and forth.

Does this setting need to be set on the server creating the backup? Or on the server restoring it?

Can you be a little clearer?

Please bear in mind that we are experiencing the problem when restoring the backup onto a brand new server that has not previously had Joomla installed.

Thanks

Ian

Wednesday, 27 May 2015 09:36 CDT

nicholas

I didn't try opcache.blacklist_filename. It should work if you set it to something like:

opcache.blacklist_filename="/etc/php/opcache_blacklist.txt"

with the /etc/php/opcache_blacklist.txt file containing something like

; Path to Joomla!'s index.php files
/var/www/index.php
/var/www/administrator/index.php
; Path to Joomla!'s configuration.php
/var/www/configuration.php
; Path to the installation directory. NO TRAILING SLASH.
/var/www/administrator/installation

This needs to be set on the target server, where you are extracting files to. Remember, your objective is to notify PHP that .php files are supposed to change, therefore not be cached. When you are creating a backup you do NOT modify .php files. When you are restoring a site you ARE modifying .php files.

Please bear in mind that we are experiencing the problem when restoring the backup onto a brand new server that has not previously had Joomla installed.

I understood that the first time :) Let me explain how Joomla! works.

When you try accessing Joomla! as http://www.example.com, http://www.example.com/index.php, http://www.example.com/administrator or http://www.example.com/administrator/index.php the index.php file of the main site directory OR the administrator directory is loaded.

One of the things it does when it's starting up is check if the installation directory exists. If it does, it replaces the path of the URL with installation/index.php and performs a redirection there. This means that it redirects to http://www.example.com/installation/index.php in our example. Both the Joomla! installation AND the restoration use this fact to place the installation/restoration script in the "installation" folder where Joomla! will find it. At the end of the installation/restoration this folder is removed.

Without a code cache Joomla! picks up the missing installation folder and continues loading normally.

With a code cache Joomla! is told that the installation folder exists and performs the redirection. At this point the code cache kicks in a second time and runs the cached installation script even though it's no longer there.

As long as you've confirmed that the installation directory has been removed after the restoration is complete you are pretty sure that the problem lies with the code cache.

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!

Wednesday, 27 May 2015 09:40 CDT

nicholas

And I think I totally missed the existence of the opcache_reset() method. I think I'll have to add that to the restoration script to make sure the cache is reset right after making .php file changes.

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!

Wednesday, 27 May 2015 10:50 CDT

leggett26

Thanks, that’s a much clearer example of what is potentially happening , and why. We will look into this and get back in the next couple of days.

Thank you

Ian

Wednesday, 27 May 2015 11:43 CDT

nicholas

OK!

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!

Tuesday, 02 June 2015 08:50 CDT

leggett26

We are having some trouble getting this to work as described.

Attached is the log of a session where we:

· Prove that opcache is switched off for both the site and cli
· Show the configuration
· Attempt to do a restore of an Akeeba backup using Unite

The result is a failure attempting to access a file in the “installation” directory.

The same thing happens if we perform a restart of the server (though we don’t have a log file attached showing that)

As we understand it, this is the process we have had described to us. Apologies if we’ve got wires crossed here.

The log file was made after a reboot of the server. One more thing, the ‘localLog’ value in the Unite inbox config file does not seem to ever generate a logfile, even when run as root (so no permission problems).

Can you help further?

Thanks

Ian

Tuesday, 02 June 2015 18:01 CDT

nicholas

A ha! The actual issue doesn't fit the description you gave me.

Here's the simple cure. Open your XML site definition file. Find the line:

<database name="joomla">

and change it to

<database name="site">

Better, also make sure you're using the latest published version of UNiTE. You seem to be using a UNiTE version from more than half year ago which wasn't aware of the changes made in Akeeba Backup 4.0 and later.

Also a good idea to upgrade your copy of Akeeba Backup to 4.2.0. The one you're using is way too old and completely unsupported.

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!

Wednesday, 03 June 2015 05:49 CDT

leggett26

Hi,

Is there a chance we could Skype you at some point. Further to your response we have:

· Changed the xml site definition file so that the name attribute of the database element is set to “site” instead of “joomla”

· Changed the version of Akeeba Unite back to v2.0.0

· Updated Akeeba Backup for Joomla to v4.2.0

· Created a new backup JPA file

Summary

It would appear that changing the database name attribute merely changes the name of the (non-existent) file that the Unite script tries to retrieve (see detail below).

The net result is that the database tables do not get created, and therefore the site is not restored.

N.B. Specifying a localLog value in the xml site definition file does not result in a log file being generated. This is presumably a bug.

It would be really useful if this worked so we have a log file left around when we build the VM and attempt to restore the site with Akeeba Unite.

Detail

Building the VM using normal process (that works just fine with a Joomla 2.5 site backup) results in:
· An .htaccess file being put in place that prevents access to the site, which I removed manually

· Re-requesting the site home page results in the error:

Error displaying the error page: Application Instantiation Error: Table 'joomla.jos_session' doesn't exist SQL=DELETE FROM `jos_session` WHERE `time` < '1433319389'

Re-booting the VM and manually re-running the Unite script with the same config results in the same .htaccess and error, but shows the following output:

root@joomla-dev:/opt/akeeba_unite# php unite.php

Akeeba UNITE v.2.0.0 (2015-03-18)

Copyright (c)2009-2015 Akeeba Ltd

This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you

are welcome to redistribute it under certain conditions. The full text of the

license can be found in the LICENSE.TXT file in the installation ZIP package.

===============================================================================

Scanning inbox for XML files...

Parsing inbox/akeeba-unite-config.xml

### Starting job #0 ###

Running validator

Running remote

Running s3

Running stealth

Writing a stealth .htaccess (direct access)

Running extract

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Extractor tick

Running dbrestore

Processing database site

Trying to retrieve installation/sql/site.sql using direct access

Could not download the site.sql file!

### Finished job #0 ###

===============================================================================

UNITE finished its run cycle

Total definitions found : 1

Total definitions executed successfuly : 0

Total definitions failed to run : 1

root@joomla-dev:/opt/akeeba_unite# cat inbox/akeeba-unite-config.xml

<?xml version="1.0" encoding="UTF-8"?>

<unite>

<siteInfo>

<package>/var/chef/cache/site-dev09.odt.joomla.local-20150601-10

5305.jpa</package>

<deletePackage>0</deletePackage>

<localLog>/opt/akeeba_unite/restore-joomla.log</localLog>

<emailSysop>0</emailSysop>

<name>Joomla 3 CF site from Ian 3rd June using Akeeba Backup v4.2.0</name>

<email>[email protected]</email>

<absolutepath>/home/joomla/site</absolutepath>

<livesite>http://localhost:8080</livesite>

</siteInfo>

<databaseInfo>

<database name="site">

<changecollation>0</changecollation>

<dbdriver>mysqli</dbdriver>

<dbhost>127.0.0.1</dbhost>

<dbuser>joomla</dbuser>

<dbpass>joomla</dbpass>

<dbname>joomla</dbname>

<dbprefix>jos_</dbprefix>

</database>

</databaseInfo>

</unite>

root@joomla-dev:/opt/akeeba_unite# php -i | grep opcache

Additional .ini files parsed => /etc/php5/cli/conf.d/05-opcache.ini,

opcache.blacklist_filename => no value => no value

opcache.consistency_checks => 0 => 0

opcache.dups_fix => Off => Off

opcache.enable => Off => Off

opcache.enable_cli => Off => Off

opcache.enable_file_override => Off => Off

opcache.error_log => no value => no value

opcache.fast_shutdown => 0 => 0

opcache.file_update_protection => 2 => 2

opcache.force_restart_timeout => 180 => 180

opcache.inherited_hack => On => On

opcache.interned_strings_buffer => 4 => 4

opcache.load_comments => 1 => 1

opcache.log_verbosity_level => 1 => 1

opcache.max_accelerated_files => 2000 => 2000

opcache.max_file_size => 0 => 0

opcache.max_wasted_percentage => 5 => 5

opcache.memory_consumption => 64 => 64

opcache.optimization_level => 0xFFFFFFFF => 0xFFFFFFFF

opcache.preferred_memory_model => no value => no value

opcache.protect_memory => 0 => 0

opcache.restrict_api => no value => no value

opcache.revalidate_freq => 2 => 2

opcache.revalidate_path => Off => Off

opcache.save_comments => 1 => 1

opcache.use_cwd => On => On

opcache.validate_timestamps => On => On

Wednesday, 03 June 2015 07:10 CDT

nicholas

Support over Skype or any other means other than our ticket system is not possible. We are explicitly stating that in our support policy. It will be a waste of your time. It won't help me help you as I will be struggling to think while I'm also trying to speak a foreign language with a native speaker of that language. I can't organise my thoughts and visualise the code workflow that way. If I can't do that, I can't help you. I can do that while I'm replying in the ticket system. I sit down, think hard and then come back to you.

As a rule of thumb, the people who propose to "solve" your problems over a Skype chat either try to upsell you to something you have no use of or want to bullshit their way out of a problem they are not inclined to assist in. People who can really help you are the quiet guys, coming with an organised troubleshooting approach and solid steps to follow.

So, back to our troubleshooting.

Please try extracting your backup archive manually. Do you see the installation/sql directory? Does it have the expected .sql files? If not, your backup is taken as a Files Only backup which CAN NOT be used to fully restore a site since, as the name of the backup type states, the backup contains only files and no database data.

If you do see the files when you extract the backup archive manually I want you to check the directory specified in the absolutepath tag. Are the files of the archive extracted there? Is the installation folder present? Does it have a sql directory inside it? If any of these answers is negative you have a permissions issue. Normally this should cause the extraction to halt with an error.

Does this installation/sql directory have the site.sql, site.s01 etc files? If not then I need your backup log file because it seems that you're not backing up your database. I want to see if there is a particular reason, e.g. you're using the Files Only backup type or you're excluding all tables or something I cannot think of but the log will freely tell me.

Please follow these steps in this order and we'll figure this out.

PS: It did take me 15' of thinking before coming back with this reply. I don't think a Skype chat with me pacing around the room, mumbling to myself and jotting things down would make you feel any more confident, right?

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!

Wednesday, 03 June 2015 09:09 CDT

leggett26

We (four people) have checked the backup settings, and confirmed that they are set to ‘Full site backup’.

To be sure, we have switched to a different setting, saved and closed, then gone back to reset the setting to ‘Full site backup’.

We have extracted the backup using Akeeba eXtract Wizard for Windows v3.3

There is no folder called ‘installation‘ in the extracted files, but there is one called 'sql' which contains sql files.

Wednesday, 03 June 2015 09:49 CDT

nicholas

OK, now it makes sense. You've selected the wrong Embedded restoration script in the Configuration page. I believe you are currently using "No Installer" which is incompatible with UNiTE. The "No Installer" setting is designed for use in old school restorations, i.e. you have to restore the SQL files manually through phpMyAdmin. It's a method designed for the very difficult servers.

What you need to do is set the Embedded restoration script to ANGIE for Joomla! sites and take a new backup.

Then try extracting locally with eXtract Wizard. You will see the installation directory and, of course, the installation/sql directory inside it. Remember that UNiTE is looking for the SQL files inside the installation/sql directory. So now that we have this directory UNiTE is looking for you can use UNiTE to restore the site.

As for the last bit I forgot to answer previously, the Stealth .htaccess written when UNiTE starts restoring the site will be removed once the restoration is complete. It will also update your configuration.php file. These steps address the remaining two issues you reported (pretty much they were the side-effect of a restoration gone awry).

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!

Wednesday, 03 June 2015 11:16 CDT

leggett26

This has worked!!!! Thank you and you can close this ticket as we understand it all now :-)

Wednesday, 03 June 2015 11:34 CDT

nicholas

Awesome! I am very glad I could help you fix this and even happier that you also understand the "why" behind the "how" :)

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