Support

The log file never came through, but I know what could have happened in this case. Just a little background. The backup is a lengthy and resource intensive process. In order to prevent a timeout or memory outage error on large backups, we have to chunk the process in multiple steps, each one happening inside one page load. Page loads are invisible, they happen via AJAX calls. Since PHP is stateless (it doesn't "remember" the application state between subsequent page loads) we need to somehow be able to save and restore the backup engine state between steps. We do that by serialising and unserialising the engine's factory, pretty much what your PC does when you hibernate it.

When you have not checked the "Use database storage for temporary data" (default) the state data is written to a file inside the output directory and read from it on the next page load. Several things can go wrong. If you run out of disk space, this operation fails. The permissions of the generated file may be askew (stupid hosts, don't ask!) which mean that Akeeba Backup can't read from the file. Other times I've seen servers which take their sweet time to release the file when we close it after writing to it. This causes the read to fail, as the file is still marked as being opened read-only. Usually we don't have any of those issues and that's why we use it as the default option.

When you have checked the "Use database storage for temporary data" we are storing this data inside the database. This is usually a very stable method. There is only one catch: some servers throw a nasty "MySQL server has gone away" and die when we try to save the data. Why? Because they are stupidly set up, that's why. These hosts are set up to close the MySQL database connection after 0.5 to 2 seconds of inactivity. Given that a file backup step may last up to 60 seconds, the MySQL connection is closed in the meantime and, worse, the server won't let us reconnect, throwing this error instead. This is more likely to happen than the file read/write issues, hence this option is not enabled by default.

Regarding your other question, the .j01 file is probably a leftover from the previous backup. Try removing both files and taking a new backup. If you see again two files, .jpa and .j01, you have a split backup archive. This is normal, especially if your host is very restrictive with respect to the maximum size of a file which can be generated by PHP code. Our Configuration Wizard automatically detects such restrictions and tries to work around them by setting up split archives, i.e. a single archive split to multiple files, each one smaller than the maximum file size allowed by the host to be created.

Phew! That was a long post. I hope it clarifies some of the stuff that's going on the background.

You have an incomplete backup. I can tell by the log file. I would recommend doing the following:
- Remove all the files from the backup output directory
- Enable the "Use database storage for temporary data"
That should allow your backups to work, UNLESS if you are running out of free disk space. As a rule of thumb, we recommend having 40-50% of your disk quota free before taking your first backup, in order to cater for the worst case scenario of disk space usage.

You are either running out of disk space or the log file gets truncated when you post it on that free service you're using, making me think that you have a problem. Please try this. Download the log file to your PC, put it in a ZIP archive and then post it here. DO NOT try to post the plain .txt message, it will NOT work, that's exactly why we tell you to "ZIP and attach your log file".

If you still can't get the log file to be attached, just send me a Personal Message (I'm user "nicholas") with the following information:
- A link back to this thread, otherwise I won't know why you are one of the half dozen people PMing me every day and I'll probably ignore your PM
- URL to your site's administrator are
- Super Administrator username and password

Ah, MUCH better!!! I now have the complete log file and, indeed, the backup is complete and without any errors. There is nothing suspicious about it. This is the exact backup size of your site.

You might wonder why your disk space usage is significantly higher than the backup archive's size. First, there is the compression factory, but that is just a small percentage of the difference. The very big percentage of the size difference is what is not being backed up:
- The contents of your site's tmp directory (temporary files). Since these are temporary files, there is no point backing them up. It would be the equivalent of keeping your trash in your closet.
- The contents of the cache and administrator/cache directories. These are supposed to be temporary files which contains pre-rendered versions of component/module output or entire HTML pages. When they are not present, they will be created on the fly. These can take an exorbitant amount of disk space. On this site the cache size is roughly 3Gb big, whereas the core of the site and its database is just a little less than 200Mb.
- Older backups. It would be quite stupid if we were backing up the old backups, as this would increase the backup archive's size exponentially. The first backup would be 15Mb, the next one 15+15 = 30Mb, the next one 30+15 = 45Mb, the next one 45+15=60Mb and so on. Why do that? No point.
- Your email accounts. The email you receive occupies disk space from your hosting account. Makes sense, no? Akeeba Backup is supposed to only back up your Joomla! site, so it doesn't try to backup your email inbox.
- Anything which is outside of the Joomla! site's root directory.

So it's very possible that a 1-2Gb site backs up to just 14Mb.