Support

According to your log file, the backup is finished successfully:

DEBUG |120413 11:36:54|Kettenrad :: Just finished

The last two lines are generated when you visit Akeeba Backup's Control Panel. You don't need to know the reason, but you can ignore them. I also don't see any other errors in that log file. Do you see the backup attempts marked as failed in the Administer Backup Files page, or do you get non-working backups?

The last lines in the log file appear when you access Akeeba Backup's Control Panel page or start a new backup. When you do that, Akeeba Backup tries to detect "stuck" backups, mark them as failed and delete the (partial) backup files. It does so by iterating through all of your profiles, trying to load the engine state and check for a special flag. The log lines you receive have to do with the attempt to load the engine state. Since your backups are complete, the engine state information file is removed, hence the "hard reset" message; it is perfectly normal, expected and desirable. That's also why you see there is a huge time gap between the last log even and those messages.

As about the "Failed" message in the Administer Backup Files page, the only way I have been able to replicate is when the update of Akeeba Backup was partial and the backup.php file (or some of the engine files) were not overwritten with the new records. The easiest way to fix that is uninstalling Akeeba Backup and reinstalling it. The only drawback is that you will lose your current settings. It's also worth noting that I have never tested Akeeba Backup with PHP 5.3.3, because PHP versions 5.3.2 and 5.3.3 are considered buggy. My tests were conducted with 5.3.1, 5.3.5, 5.3.7, 5.3.9 and 5.3.10. I'd suggest also upgrading your PHP version, in case one of the numerous bugs is affecting Akeeba Backup (I have no way to check that, sorry).

Finally, regarding the extraction, in the case of Kickstart seem to be entering the wrong password. That's why it fails at offset 8 (offset 8 is right after the file header, where the encrypted data starts). Either that, or the target server doesn't have mcrypt installed or doesn't support the AES (Rijndael) encryption scheme in PHP's mcrypt extension. Regarding the Akeeba eXtract Wizard failing after 33% of extracting, I need to know if it has extracted any files, if they are properly named and if their contents are garbled or not. If the filenames or the file contents are garbled, you are entering an incorrect password. If not, you may be missing backup parts (you need the .jps as well as the .j01, .j02 and so on files created during the backup).

The thing is, the log says a different story. According to the log, the backup hasn't failed. The backup is complete and all 10 backup parts (.jps, .j01, ..., .j09) have been transferred by FTP to the remote storage. I don't understand why that backup is listed as failed. I have the same setup on this very site: Joomla! 2.5.4, PHP 5.3.10 (that's our difference) and Akeeba Backup 3.4.3. I am backing up with CLI; it's been months since I last used the back-end backup on this site. My backups are correctly listed as "Remote".

Let's try two more things, if you don't mind:
1. Take a cli backup after disabling the transfer to remote FTP. Does it still list the backup as failed?
2. Try using JPA instead of JPS (and enable the transfer to FTP). Does that list the backup as failed?

This will help me try isolating the reason of the backups displaying as failed, despite having completed correctly.

OK, this is getting somewhere. There is certainly a problem with JPS archives. I will take a look into it, but the fix will only make it to the next alpha release (3.5.a1), scheduled for mid- to late May.

OK, I just did some more testing.

The Failed status has to do with the way the CLI mode and the JPS format work in Akeeba Backup up to and including 3.4.3. Starting with 3.5.a1 we'll be using Joomla!'s native CLI mode (introduced in Joomla! 1.7) and the backup archives are no longer listed as Failed.

Regarding the JPS extraction, it turns out that the eXtract Wizard support for JPS archives is buggy and I can't fix it. You can, however, use the latest published version of Kickstart to extract those archives that eXtract reports as broken. It's very important to use the correct password. Ideally, the password should only contain lowercase and uppercase letters without accents (a..z, A..Z, but not ç, é and so on), numbers, spaces, dashes, dots and underscores. Anything else has the potential to be translated to UTF-8 by the browser and cause extraction issues.

I hope that helps a bit until I get to the point where I can release a new alpha release.

Yes, that's correct. I can (already have, actually, but the current state of the codebase is not stable enough) fix the "Failed" status for archives generated by the CLI. I just won't be able to fix eXtract Wizard's issues.