Owner's reply: Scheduled backups have always been possible with Akeeba Backup Core since it was called JoomlaPack back in 2007. In fact, the free version allows you to take scheduled backups in two different ways:

1. Frontend backups for use with CRON. Documented here https://www.akeebabackup.com/documentation/akeeba-backup-documentation/automating-your-backup.html#frontend-backup and also described in great detail in the component itself. You can also find a video about it, used in conjunction with WebCRON in https://www.akeebabackup.com/documentation/akeeba-backup-documentation/automating-your-backup.html#frontend-backup This is the method we have supported for over 10 years. Documentation and videos are linked to by the component and are free of charge.

2. The JSON API which can be used by our free of charge Akeeba Remote CLI (see its free of charge documentation at https://www.akeebabackup.com/documentation/arccli.html) or through third party services such as myJoomla and Watchful. We DO NOT make money out of these third party services because, well, they are third party...

Regarding the paid version, it adds exactly two (2) additional methods:

a. A CLI script which uses the front-end backup method. This is a more complicated version of the script we already give you for free in the Automate Your Backup page of the free of charge version of our component. The main difference is that it is more verbose and gives you exit codes which can be used in automation. Really not that much different than using cURL or wget.

b. A pure CLI backup script which does not go through the web server at all. Yes, this is something not provided in the free version.

All of the above do require you to set up a CRON job on your server or use a third party service. When Paul emailed me about his review I sent him a long explanation why this is necessary. Please let me copy & paste here (it's a LONG read).

There is a very good reason why we don't allow backups to happen "magically", e.g. through a system plugin: backup consistency. I am not making this up. Back in 2010 to 2012 we had a system plugin which would "magically" take scheduled backups, the Lazy Scheduling plugin. However it had several shortcomings.

The backup is a very long and resource intensive process. You cannot run the backup of an entire site in a single page load because you will run afoul of PHP's time limits, your web server's time limits, PHP's memory constraints, your database's query limit, your host's CPU usage limits or your host's I/O limits. Basically, if you don't have a tiny site on a dedicated server it will fail. That's why the backup process in the backend uses AJAX to make multiple calls to the server, each call progressing the backup just a fraction, until the backup is complete.

This does not translate very well to an automatic backup which does not use CRON. PHP is stateless language, i.e. it only executes when you call a page without having any context of what happened before that call or in parallel with that call. This means that you need something to trigger the backup and keep it progressing. If you can neither have a CRON job nor a third party service doing that for you the only trigger that's available to the system is visitor activity. However, this creates some issues.

You can only take backups when there's plenty of user activity. You need a steady stream of traffic. This is all but impossible on the small sites which would benefit the most from such a backup method. What we had seen is that backups which take 30 seconds in the backend took 2 days or even weeks to complete with the "magic" scheduled backup. This was due to a lack of activity from users.

The other problem is that you need the user to stay on the page. If they close their browser while the backup is executing most servers will drop the connection and kill the script. This has the effect of corrupting the backup archive since the backup taking code was abruptly stopped in mid-process. The next time we try to step through the backup process bad things will happen.

Since you are relying on user activity it is guaranteed that the backup is being taken when data is more likely to change. Therefore you have a problem with the backup consistency. This is not a big deal with regular backups since the backup is short enough to provide an acceptable level of consistency. The "magic" backups were resulting in highly inconsistent backups, therefore restoration errors.

There are many more reasons why this solution backfired spectacularly. I came to the inevitable conclusion: its very nature means that it cannot work reliably. That's why I removed it. I used to have the reasons for removal in the documentation until less than two years ago. Using a regular CRON job or a remote service is the best way and reliable way to schedule backups.