Support

The first thing to remember is that code is neither sentient, nor magic. It cannot tell itself to run; someone or something else has to do that.

As per your log file, the backup runs because there is a WP-CRON schedule telling it to run. This cannot be installed without user interaction. In other words, it's something that you or another administrator set up. To be clear: a human interacting with your site's Akeeba Backup installation did it.

Go to wp-admin, Akeeba Backup, and click on the “WP-CRON Scheduling” button in its title bar. You will find your schedule there. You can delete the entries to stop the backup from running automatically.

You came here with a very strong confirmation bias. Unfortunately, this makes you have a very closed mind and not accept anything I say. I do technical support. It deals in facts. If I provide facts which challenge your preconception it's not condescension, it's merely a pragmatic approach to solving your problem.

For my part, I approach every technical support ticket with an open mind. If it's not something I have seen before and can readily explain, I will use the objective information at hand and my knowledge of the code, how servers work, etc to come up with plausible theories which I then try to prove. By using reductio ad absurdum I will arrive at the root cause and offer a solution. I will never accept explanations which require absurd means, such as sentient machines, or magic. These do not exist in the real world. Everything has a technical explanation.

I did exactly that before replying to you. I am happy to expand on it, seeing you did not appreciate my previous response.

I know for a fact that I am the maintainer of the software in question. I have written all of its code, or code reviewed and step-debugged all parts of the code written by my co-developer. I know all of the code in very intimate detail. Because of this, I know for a fact that I have not written any code to add WP-CRON backup schedules automatically. Before I continue, please allow me a diversion on why I made the conscious, and well-reasoned decision not to write any such code.

The software cannot possibly decide to set up WP-CRON scheduling on your site because we don't know if, how, and when you want your backups automated. We do not know which automation method you'd prefer (if any at all), which backup profile you would like to use, whether you have already set up your backup profile, whether the backup can run at all, when you want the backup to run, and how often you want the backup to run. Not knowing if, how, and when you want your backups automated is reason enough not to automate your backups without your explicit input. But that's not the only reason.

The other obvious reason is a benefit-cost analysis. What are the benefits and costs of automating backups without asking you? In the extremely unlikely case we get it right we saved you a grand total of two clicks. Big whoop. In the far more likely case we get it wrong –that would be the vast majority if not totality of your sites– it would lead to problems with the backup, or even the site's operation (resource usage at peak times, running out of space, …). This would lead to a lot of unnecessary friction with the users. The benefits are thin and dubious to justify this kind of action to our clients. As a result, this action would only lead to client resentment, which would lead them to abandon our software. We gain virtually nothing, and we risk losing everything. This course of action is business suicide, which is yet another major reason not to automate your backups without your explicit input.

Going back to your question about whether it's magic or a bug, I can tell you that it's neither.

The definition of a bug is a design defect in computer software. However, I have not written any code to do what you allege, for the reasons I explained above. I have not even written any code even remotely related to that kind of automatic action, let alone code of that sort which could run on installation or update. Since there is no code (software) for the alleged behaviour then, by definition, there can be no bug.

But, as I said, I keep an open mind. Could it be “magic”, i.e. an unexpected/unwanted behaviour from some other, unrelated, piece of code already written, or an unwanted interaction with something external to our software? Well, that's a theorem. We can disprove it using objective facts. You alleged that the upgrade to 8.2.7 added WP-CRON backup schedules on your site. Version 8.2.7 was released about a month ago, on October 20th, 2024. Thousands of sites –including my own testing and production sites– have been upgraded to it. Yet, nobody has observed or reported this alleged magic addition of a WP-CRON backup schedule taking place. Do remember than when there is an issue, especially a major one like this, it takes an average of three hours to receive several tickets about it, as it happened for example when WordPress 6.3 broke plugin updates. This is the blessing and the curse of having a popular, mass-distributed piece of software; major problems missed in testing become apparent very, very quickly. The fact that nobody else has observed or reported it over a month means this isn't happening to anyone else. Since code is deterministic, it means that it's not happening to you either.

If it's neither magic nor bug, what is it?

I have two plausible explanations for that.

It is possible that you had set up a WP-CRON backup schedule in the past but abandoned it as it appeared to do nothing. There was indeed a bug in Akeeba Backup versions prior to 8.2.5 which prevented WP-CRON backup schedules from executing on some sites because our WP-CRON schedule definition was not applied to WordPress consistently under all possible execution modes. This was fixed in Akeeba Backup 8.2.5. This means that if you upgraded from an Akeeba Backup version 8.x lower than 8.2.5 to Akeeba Backup 8.2.5 or later (including 8.2.7) these WP-CRON scheduled backups would “magically” start working again. Of course there is no magic, it's just that the bug was fixed. Since the time between setting up the WP-CRON backup schedule and it started working again would be several months or years it is reasonable that you have no recollection of it ever happening.

Moreover, the WP-CRON backup scheduling interface was present in Akeeba Backup Core, but the code for executing scheduled backups wasn't. It is possible that you had set up your WP-CRON backup scheduling in the Core version, found it not to be working, then moved on to the Professional version but because of the bug I explained in the previous paragraph you'd still not get automatic backups with WP-CRON, so you set up scheduled backups in a different method. Come the upgrade to 8.2.7 and now the WP-CRON scheduled backups start working again, and you're caught by surprise because you no longer remember that they were set up in the first place.

As you can see, yes, it is possible that you or another administrator set up WP-CRON backup scheduling and forgot about it because for various reasons it appeared not to work. When it started working, you no longer remembered doing that and assumed that the schedule was added by code which does not, in fact, exist. You will of course tell me that it's my word against yours.

Or is it?

You see, you have backups taken before the upgrade to Akeeba Backup 8.2.7. It would be fairly simple to restore a backup just before upgrading to Akeeba Backup 8.2.7 on a temporary subdomain and check Akeeba Backup's WP-CRON page. Of course, if you see no schedule this doesn't mean one wasn't created after the upgrade. You can restore further backups to examine that as well.

In any case, we have determined by your log file that the problem is WP-CRON bacup schedules. As I told you before, the solution to this problem is to go to wp-admin, Akeeba Backup, and click on the “WP-CRON Scheduling” button in its title bar. You will find your schedule there. You can delete the entries to stop the backup from running automatically.