Support

Akeeba Backup for Joomla!

#14697 Backup sql file is incomplete

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
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

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Monday, 21 January 2013 01:20 CST

hollai

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.10
MySQL version: 5.0.96
Host: (optional, but it helps us help you) Hostgator VPS
Akeeba Backup version: 3.6.12

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:

 

I have been running backups on my site on a regular basis. Since about a week ago, the sql files in the backups deem to be incomplete. If I restore a site in a different user acount on the samae server the site I am restoring doesn't load until I manually copy the sql file.

I ran Admintools permission fix and also check the PHP memory limit. I suspect some config change in my server but I cannot pinpoint a problem as I am not aware of any  changes. Can you please advise how the problem can be solved?

Thank you,

Tom

 

hollai

Hello,

 

I apologize, my session timed out and I didn't notice that I was sending my ticket blank.

I read the previous tickets and the documentation.

My host is Hostgator VPS / PHP: 5.3.10 / MySQL: 5.0.96 / Akeeba: 3.6.12.

Issue:

I have been running backups on my site on a regular basis. Since about a week ago, the sql files in the backups deem to be incomplete. If I restore a site in a different user acount on the samae server the site I am restoring doesn't load until I manually copy the sql file.

I ran Admintools permission fix and also check the PHP memory limit. I suspect some config change in my server but I cannot pinpoint a problem as I am not aware of any  changes. Can you please advise how the problem can be solved?

Thank you,

Tom

nicholas
Akeeba Staff
Manager

The only database data not being backed up are:

  • Finder (smart search) data. You can run the indexing again in the restored site's back-end.
  • Session data. These are not required (the sessions are generated when you login)

There is nothing in the archive which hints at a problem with your site. Perhaps if you could elaborate on the "doesn't load" part of your message I could help you.

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!

hollai

Hello Nicholas,

 

I have done some further exmamination this morning. Here is the fresh info.

So far I have two sites that don't restore:

  1. ow.exquison.com
  2. ma.exquison.com

1. The backup log I sent yesterday belong to the first case. I back up this site every day and the last backup that works was generated on Jan-4. This is an application that is password protected. (orig: office.ellismoving.com)

2. I attcah the backup log and the sql files pertaining this case. (maexquis_ ma.sql is the incomplete backup sql file) The url of the orig site, which we are building now, is this: metal.exquison.com .

 

I tried coping an other site on the server and fortunately it did work. So, this is not something the occurs accross the whole server. I will do some more backup-copy test to see if other user accounts are affceted.

 

Thank you,

Tom

 

 

 

 

 

nicholas
Akeeba Staff
Manager

The strange thing I see is that all tables report 0 records! I can't explain this. Akeeba Backup runs a "SELECT COUNT(*) FROM tablename" for each table to determine how many rows it contains. Then it runs simple commands like "SELECT * FROM tablename LIMIT 0, 1000" to get (in this example) the first 1000 rows. It uses the same database connection as Joomla!. I have no idea why your database server doesn't return any data. Maybe ask your host if they changed something?

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!

hollai

I thing I noticed that many of the file and folder permissions got altered e.g. from 755 to 750. I ran Admintools permission fixes, so the useraccounts in question should have appropriate permissions in the public_html.

Please let me know if you have any advice re how to specify the question I need to ask from Hostgator.

 

Thanks a lot,

Tom

 

nicholas
Akeeba Staff
Manager

Hello Tom,

Permissions have nothing to do with this. We're not talking about files, we're talking about database data. Doing a SELECT * FROM table LIMIT 0,1000 is supposed to return the first 1000 rows of the table no matter what. I don't understand why Joomla! can list that data but Akeeba Backup, issuing the same SQL statement, cannot when they are both looking at the same database.

Hm, wait a second! Before contacting your host, can you please check your Akeeba Backup Configuration? I suspect that you have accidentally entered something in the Sites Override section, causing this issue. I am suspecting that you are telling Akeeba Backup to look at a different database.

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!

hollai

Oh crap, I am running the backups on all my user account from one "central" useraccount and at this case I missed out the checkmark from the database override, so the backup was made with the wrong sql. This hopefully is a false alarm - I apologize for this.

How about case #1? Do you think the missing session and finder tables has to do with server config?

 

I will do a backup-restore test for case 2 in the mean.

 

Thanks,

Tom

hollai

So, I restored the metal.exquison.com user account to ma.exquison.com - this time with the right database override setting unfortunately there is still some problem to the sql backup - altough this problem looks to be different to case 1.

Please see atached the backup log and the sql files. (maexqui_ma is the backup sql) The difference between the orig and the backup sql seems to be in lines 509, 626, 7784, 7794, 7796, 9653, 9654.

In these lines of the backup sql there are references of a prefix (k9yqn), which was the prefix of the orig sql database. I changed it by Admintools to the current prefix a few days ago.

 

Thanks,

Tom

nicholas
Akeeba Staff
Manager

Tom, why are you using a database override to backup your site? You do not need this and should not use it. The only reason this option is there is to allow you to backup Site B using an Akeeba Backup installation on Site A.

Now, regarding your SQL diff, the differences you mentioned are (btw, you are one line off in all of them):

509: it's a comment

626: It's a comment

7784: It's a comment

7794: It's a comment

7796: It's a comment

9653: It's a comment

9654: It's a comment

So, the ONLY changes you saw are in COMMENTS. Something like 

`group_id` int(10) unsigned NOT NULL default '0' COMMENT 'Foreign Key to k9yqn_usergroups.id'

becomes

`group_id` int(10) unsigned NOT NULL default '0' COMMENT 'Foreign Key to #__usergroups.id'

in the backup archive. This is because all table prefixes in the create table SQL statement are replaced with #__. Moreover, these are comments. They haev no functionality whatsoever.

As a result I have to conclude that this ticket is a red herring and the backup works just fine. Something else is going wrong in your site. As I told you earlier:

Perhaps if you could elaborate on the "doesn't load" part of your message I could help you.

When I ask questions like that it means that I suspect that you're wrong. Giving me this information will help me help you. If you don't want to tell me what "doesn't load" means (blank page, web server error 500, Joomla! error page, PHP error, missing formatting on the page, missing images, clicking on links doesn't work, ... it's TOO MANY possibilities for me to guess!!) I can't help any more.

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!

hollai

Hello Nicholas,

I apologize for not giving you staighforward enough info.

If you go to the restored site -  ma.exquison.com - then this is the error message:

Table 'maexquis_ma.k9yqn_session' doesn't exist SQL=INSERT INTO `k9yqn_session` (`session_id`, `client_id`, `time`) VALUES ('64442d5da3acc2c98c61d88d35c87dc4', 0, '1358582170')

 

Again, if I manually copy the sql file over from the orig user account to the new user account then that solves the problem.

 

BTW, you asked about the override setting. The way I am using your Akeeba Backup is that I have one joomla installation on my server with Akeeba Backup and I am using this installation to backup all the rest of my user accounts on the server. This lets me manage all my Akeeba crone jobs from one useraccount and there is only one place I need to refresh Akeeba. Pls let me know if you think this is not the way I am supposed to use Akeeba - I though this was a pretty kickass feature!

Enjoy the weekend,

Tom

 

 

nicholas
Akeeba Staff
Manager

Ah, OK, now it makes sense. Yes, you should use the site overrides in your case. In fact, you should use both the db and site root overrides for this kind of backup to work.

Now, back to your issue. The error message tells me that one of the core Joomla! tables is not restored correctly or that your configuration.php is not updated correctly.

Extract the backup archive using Akeeba eXtract Wizard and take a look in the installation/sql directory. Look into the .sql, .s01, ... files. There should be a line starting with something like:

CREATE TABLE `#__session`

If this is not present please send me the log file from the backup so that I can see why the table is not included in the backup set.

If, however, that line is present please retry a restoration. Note down the database hostname, username, password, database name and prefix. After the restoration is complete check your configuration.php file. Does the information in the configuration.php reflect the values you noted down? If not you'll have to update the configuration.php file manually.

If the configuration.php file is up to date check your database. Does the table #__session (replacing #__ with your database prefix) exist?

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!

hollai

Hello Nicholas,

I have to apologize for sending you false alarm.

It turns out that in both cases the prefix wa not correct in the Akeeba backup config. In one case, I chnaged the prefix of the given site in the Admintools and I forgot about it. In the other case, my colleague created a new sql database with a new prefix that I was not told about... It made the situation worse that I noticed that the backups were not running properly at the same time leading me to believe that it was a problem across the whole server.s

I am terribly sorry for taking up your time with this & really appreciate your attention.

Have a great week,

Tom

 

p.s.: The Akeeba centralize backup feature is totally cool!

nicholas
Akeeba Staff
Manager

No problem! At least there is a reasonable explanation to what happened :)

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!