Support

First of all, thank you for your subscription!

Regarding the backup speed, Akeeba Backup 7 is nearly 10% faster than Akeeba Backup 6 but this is mostly seen in files backup., not database backup I can tell you what I see in the (partial) log files you've sent me. You have a big database. At the 15' mark Akeeba Backup was still backing up the database and that's as fast as PHP can go – there's barely any room for performance improvement there, about 0.1% that would come with great pain and a massive time investment. Understandably, it doesn't make sense for us to pursue that. In any case, it makes sense that your entire backup would take 40' or so to complete. Backing up the database is always the major bottleneck in any backup operation. Not just with Akeeba Backup but even with MySQL's own mysqldump! Take it from someone who migrated two development environments with MySQL databases several GBs big on new laptops in the last 10 days. Backing up and restoring the databases was the bulk of my time. Backing up and restoring 4x bigger file data took a tenth of that time. That's an insane difference but it's also reasonable due to the way databases work. At best you can look for any database data you don't need to back up and exclude it from your backup. Besides that there's really nothing you can do to speed up your backup.

Regarding the CLI backup, your log file says it works. However, after about 7' to 15' your host terminates it. This is not under our control. This is something implemented on your server, by your host. It's the CPU time limit in the Linux user limits (ulimit -t). After the CRON job has used the CPU for this many seconds the process is terminated. The fact that it seemingly takes a random amount of time when using the akeeba-altbackup.php script is reasonable and expected. The time limit is applied to the akeeba-altbackup.php script which merely calls a URL and waits for it to return. It only consumes CPU time when sending the request and receiving the response. The backup itself doesn't consume CPU time in the same process. Since the backup itself runs inside a web server thread it may go a bit slower or faster depending on the server load. This, in turn, changes the "wall clock" time that elapses for the same amount of work expended by the akeeba-altbackup.php script. I understand how counter-intuitive this is. It messed with my head 15 years ago when I first encountered this behavior. Once I understood the difference between CPU time and wall clock time it made perfect sense for very Engineer values of "perfect sense".

So, to sum it up. Your site has a big database. Backing it up takes a lot of time. This is the limiting factor to what you can and cannot do. You may be able to convince your host to increase the CPU time limit for your CRON jobs to run backups without WebCRON unless you're on shared hosting or a cheaper VPS. If they decline: WebCRON works for you, keep it as a viable option.