Support

I would suggest trying to switch between the MySQL and MySQLi (without and with an i) database drivers. Does that help?

I have made this ticket private so that only you and me can see the information posted here. I will need some further information in order for me to help you.

In order for me to help you fast and accurately, please provide the information by copying the form below, paste it into your reply and fill in the information:

----- Access Information Form -- START -----

FTP connection information

• FTP methods supported (e.g. FTP, FTPS, SFTP):
• FTP Hostname:
• FTP Username:
• FTP Password:
• FTP Port (if other than 21 for FTP and 22 for SFTP, ask your host):

Database connection information

• Database server hostname:
• Username:
• Password:
• Database name:

Site access

• URL to the site you are restoring to (e.g. http://www.example.com):

Control panel access (Optional, but very useful)

• URL to access the control panel:
• Username:
• Password:

Make sure that you have run the Kickstart extraction up to the point before clicking on the Run the Installer button. Do not delete the backup archive or the installation directory from your site.

----- Access Information Form -- END -----

Please allow up to one business day (GMT+2 timezone) for me to log in to your site and debug this issue. When I'm done I will post back. Once the issue is fixed, you can revoke my access e.g. by changing the FTP password.

Oh, it seems my previous reply didn'y come through! I did check your site, but I see a huge problem: the database dump file (installation/sql/joomla.sql) is 0 bytes long. This means that this backup is either from a files-only backup (no database dump was made) or that Akeeba Backup was complaining about a database connectivity issue when you were backing up your site and you ignored it.

The thing is, there is no backup of your database in this backup archive. Do you have any other previous backup archive which we may use to get at least an older version of your database?

I made you pay?! What the heck are you talking about?! Your ticket was submited on November 29th, 2012 02:16 UTC. I was asleed at that time as I live in UTC+2. You got your first response by yours truly just 7 hours later, as soon as I woke up. Upon receiving your reply you got a response in 1 hour. Then YOU delayed replying for DAYS even though you very well knew that your support subscription only lasted 8 days. How am I liabble for you delaying resonding to YOUR ticket and supplying me with information is beyond my understanding. Your decision to renew the subscription is also yours and only yours. I DID NOT ask you to renew the subscription. YOU decided that.

Moreover yuo have to understand that the information you supplied was INCORRECT and I had to lose half an hour on them:

• The FTP account you gave me connects to a directory which contains only two files, .ftpquota and maintenance.html. Obviously you didn't pay any attention when you were creating the FTP account or you would know that you assigned a different FTP root than the one necessary to help you.
• Upon seeing this I thought, OK, let's try creating a new FTP account with cPanel. Your cPanel access information does work, but results in a page which tells me that I am trying to access cPanel from an unknown IP and requires me to enter the answers to four personal questions. Since I don't know your mother's maiden name or your date of birth I couldn't continue.
• So I thought, OK, let's just try accessign Kickstart. Nope. No go. You had the stealth .htaccess in place which prevented me from accessing your site.

At this point I was poised to abandon my try. Instead, I took a walk and starting considering how the bloody hell I can help you. After another 15 minutes the idea struck me: the cPanel login information also serves as the default FTP access username and password. I tried that and I was now able to connect to your site by FTP, remove the .htaccess, run Kickstart and check what is going on. So, yeah, it seems that all the while I was busting my ass trying to help you my session on the ticket system expired and the answered I typed didn't come through. Given the torrent of work I have today and the dozens of tabs I keep open, I didn't notice that I got an error message. Excuse me for trying to help you, I should have probably just replied that the information is wrong and close the ticket.

It's also very well beyond my understanding how I am liable to your failure to check that your backup is indeed working. Moreover, do note that whenever Akeeba Backup cannot connect to your database it issues a warning. You claim to be using CRON backup. The real CRON backup script has never been available to non-subscribers. Therefore I guess you mean that you are using a CRON script which runs a front-end backup using CRON or cURL. In this case there is no warning printed out because of the backup method you are using. It is, however, printed out in the log file. Did you read the log file? Did you test your backup to make sure it's working? How am I supposed to that for you, people? It's not like I have access to your sites.

Wait a second. You just said:

I CHECK AMAZON S3 AND SEE THE DAILY BACKUPS.  ALL LOOKED GOOD TO ME.  THEY ARE EVEN THE SAME SIZE FILES AS THE PREVIOUSLY FINE BACKUPS. 

I suppose that the "previously fine backups" means "tested backups". In this case you do have backups with a database in them.

BUT YOUR SOLUTION IS TO BLAME YOUR PAYING CUSTOMER FOR NOT MIRACULOUSLY KNOWING THAT THE BACKUPS STOPPED BACKING UP THE DATABAS??!

Miraculously? Did I even imply that? All I am saying is that I am not personally managing the backups of your site. As a precaution you are supposed to do test your backups. I will give you an example of what happened to me 10 years ago. I was backing up all my files on a CD-ROM (do you remember DirectCD? That's what I was using). I thought that they were safe. Then my hard drive crashed. It so happens that the CD-RW I thought I was backing up to had developed a defect which prevented me from reading most files from it. Whose fault was it? The CD-RW manufacturer's? The CD-ROM drive manufacturer's? Microsoft's? DirectCD's? The hard drive manufacturer's? Or maybe mine? I considered it my fault because I never bothered checking that the backup was actually working.

Just like any other software running on your site, Akeeba Backup is bound by the settings of your server environment. If, let's say, the privileges for the database user change at some point and SHOW TABLES is not allowed then it "sees" no tables and logs that no tables have been found. Did you check the log? Did you try to do a test restoration? Are you 100% sure, beyond any doubt whatsoever, that nobody changed anything in the server configuration? I don't understand how that is my fault. Have you hired me to take backups of your site and test them, under penalty for lost data? I don't think so.

What kind of a response do you honestly expect from a person who is desperate for your help to restore their site after going through your trouble shooter repeatedly, and then you just tell them there is no database in the backup file and try to blame THEM!

What kind of a response do you honestly expect from a developer when the truth is that your database dump is not present in the archive? Do you think I am in posession of a magic formula which can restore data that's never recorded anywhere? Of course not. That's why I asked you if you have a previous backup.

So, coming back to my previous question. Have you actually tried restoring any of the older backups? You just said that older backups are "FINE". I presume this means tested and restoring correctly. Well, do you want to try restoring one of them?

Also, there is another thing. I have no idea what your free disk space on the account is because the login information you gave me doesn't allow me to log in to your cPanel. If your disk is full it makes sense that the SQL dump is reported as 0 bytes (it wouldn't be able to be written to). Maybe instead of yelling you could try extracting the backup locally using eXtract Wizard and see if the installation/sql/joomla.sql file is non-zero bytes long.

Look, I do try to help everyone to the extent it's humanly possible. You freaked out on me when I told you that you don't have a SQL dump in your archive. I gave you two possible explanations and you immediately started yelling at me. Had I been provided with a backup log file (which is obviously out of the question on that site) I could have told you EXACTLY what happened. Not given a log file I have to speculate and by doing so I had to list the most common and plausible reasons.

First of all don't shout at me.

Your personal information is nowhere to be found on the ticket. You do realise that I had already removed it before making it public.

The ticket was made public because of the way you're behaving. Knowing how people like you would react in a situation like this I want to have my bases covered and be able to demonstrate beyond any doubt what I wrote to you and what you replied back.

Finally, since you're not even reading my replies (unless you are MIRACULOUSLY –as you so eloquently put it– capable of reading, comprehending and ingoring all 7 paragraphs of my reply in less than 2 and a half minutes) I am going to close this thread and close your account. 

Goodbye.