Support

Refunds are not possible for two reasons. The first is that you are subscribing to a software download service. Since software is not a tangible good you can't simply return it and get a refund. The second - and most important reason - is that there is a free, fully functional version which you can try first (and this issue should be also happening with the free version).

That being said, I'll try helping you, but I need your cooperation with this. Please go to Akeeba Backup's Configuration page and click on the "Configure..." button next to the database dump engine. In the pane which opens below, please make sure that:
1. MySQL Compatibility is set to Default.
2. Dump PROCEDUREs, FUNCTIONs and TRIGGERs is cleared (not checked).

Now, take a look at the documentation. It explains why you need to do that. Let me copy the important section:

Dump PROCEDUREs, FUNCTIONs and TRIGGERs



By default, Akeeba Backup will only back up database tables and VIEWs. If your host supports this, you can also back up and restore advanced aspects of your MySQL database: stored procedures, stored functions and triggers. If your site makes use of any of those features you will have to tick the box. If the backup operation crashes or you the database tables filter page is blank you must turn this option off for Akeeba Backup to work properly.



Warning



Using this feature requires that your host allows you to execute privileged SQL commands against the MySQL database:



*



SHOW PROCEDURE STATUS

*



SHOW FUNCTION STATUS

*



SHOW TRIGGERS



Most shared hosting providers do not allow you to execute these commands. Trying to do so will usually cause the script execution to abruptly halt, most often without indicating the source of error. If you are in doubt, disable this option and retry backup. This shouldn't be an issue with dedicated hosting, as long as you grant the SUPER privilege to the database user you use to connect to your site's database.

If you send me a private message with authentication information to your site, I will fix a.s.a.p.. I prefer fixing issues than issuing refunds. Not so because I don't like giving money back to the clients, but because it's a far better service level getting the software to work. Hopefully, most (all?) users share the same mindset. So, just PM me and I'm onto it!

Thank you for providing me the login information to your site. I have fixed the issue and you can now safely take backups.

Background information (especially useful for future searches). Your site had tables with jos_, bak_ and #__ prefixes. The former being your normal site prefix and the second one being the default backup tables prefix they would work just fine. However, the latter is not supposed to be ever present in your database. I assume that it was the result of trying to restore a database only backup of an early JoomlaPack release with phpMyAdmin? The problem began there. Akeeba Backup internally translates the table names into their "abstract" form, substituting the real prefix (in your case jos_) with the standard Joomla! meta-prefix #__. Since there were now two tables with the same name in Akeeba Backup's internal lists, the table dependency scanner would go haywire and enter an infinite loop.

The fix was two-fold. First, since tables with the #__ prefix would cause a restoration error and are, anyway, not supposed to be in your database, I forcibly exclude them from the backup set. The other part of the fix was a bug which wouldn't let the engine catch the infinite loop condition and bail out. This bug is present ever since Akeeba Backup 3.0.a1 and was also present in the "MySQL 5" engine of JoomlaPack 2.3 and later. However, your site was the first one to trigger it.

Acknowledging that this was a bug, please accept my apologies. I have upgraded your account to the "Deluxe" level, which entitles you to direct support through our support tickets system. If you need assistance with backing up or restoring your website, please use the ticket system directly. The major benefit is that I personally reply to all tickets, usually within minutes and no longer than 24 hours -- except on the days of support unavailability which are posted on the calendar at the bottom of the right sidebar on our site's front page.

Thank you for your kind words! We try to provide the best holistic user experience - no matter how hard we have to work towards that goal :)

Regarding your request, it is absolutely possible, but you have to know a bit about the Linux command line and how bash scripts work. To cut a long story short, create a file named backups.sh containing the following:

#!/bin/sh
php /path/to/site1/administrator/components/com_akeeba/backup.php --profile 1
php /path/to/site2/administrator/components/com_akeeba/backup.php --profile 1
php /path/to/site3/administrator/components/com_akeeba/backup.php --profile 1

The important is the first line: sha-bang followed by /bin/sh with no space in the middle. This is a magic string which instructs Linux that this file is a shell script. The following lines contain one CRON job backup command per line. All lines should be terminated with UNIX line endings. If you are creating this script on Windows, make sure you upload it in ASCII mode and your FTP software will take care of the line ending conversion.

Once uploaded, you have to make it executable. Assigning it 0755 permissions with your FTP software is adequate. Then, you simply have to modify your CRON job command to run this script, i.e.

/bin/sh /path/to/the/script/backups.sh

You need to check with your host if they allow running shell scripts through CRON jobs. Some hosts are very stringent with allowing this kind of scripts, most don't have a problem. It certainly works on most commercial VPS environments and - naturally - works just fine on dedicated servers. It's all up to the host if they want to allow you running shell scripts.

If this doesn't cut it - for example your host disallows running shell scripts - we can create a PHP-only solution.

This is not very difficult, but it takes a Linux geek to understand it :D

Important rule: DO NOT SUFFIX YOUR COMMAND LINE > WITHOUT SPECIFYING A TARGET DEVICE AFTER IT. IT IS A SYNTAX ERROR.

That stressed, let's see why. "> /dev/null" means "redirect the output to the null device". The > is the output redirection symbol. It expects something after it. /dev/null is the null device, a.k.a. the "bit bucket". It is a black hole: anything gets in, nothing goes out. If you append this to the command line, you will simply receive an email with no details of what ran whatsoever. I discourage using it in conjunction with the backup scripts, as the backup scripts generate useful information, so is prudent to have them echoed to output so that they are emailed back to you when the CRON job finishes running.

The command line should look like:

sh /home/myuser/data/scripts/backups.sh

As a side note, I am not sure if you are aware of this, but Linux and Windows use different characters for line endings. Linux and Mac OS X use a single new line (\n) while Windows uses a carriage return and a new line (\r\n). If you edit the shell script in Notepad and try to use it, the Linux shell interprets the Windows line endings (enforced by Notepad) as an error. Solution: use the free Notepad++ application to edit your shell scripts. Before saving, go to the "Format" --> "Convert to UNIX format" menu item. This will fix the newlines in Linux style, as the shell expects them to be. Upload the fixed file back to your server and it should work.

Finally, there should be no other character in the file before the sha-bang (#!). This means that there should be no other line and no whitespace before it.

I hope this crash course in shell script pitfalls will be helpful :)

You are not doing exactly what I tell you to do :)

As I said, the command line should look like:

sh /home/myuser/data/scripts/backups.sh

There is no > character at the end. Not ever > /dev/null. You have entered this command line:

sh /home/*****/data/scripts/backups.sh >

Spot the difference between the two command lines? Good. Remove that greater-than sign off your command line and retry.

In the backup.sh script file we start each line with "php" which runs the system-wide PHP version. Unfortunately, that's PHP4 and Akeeba Backup requires PHP5. You need to ask your host what is the path to the PHP5 binary, then replace "php" in the backup.sh file with that path. If it's, let's say, /usr/local/bin/php5-cli you should have lines looking like

/usr/local/bin/php5-cli /path/to/backup.php

Since the path to the PHP5 binary is host-specific, the only way to find that out is asking your host, i.e. submitting a support ticket with them.