Alain Raap

Ken, we could shake hands  I found the same resolution/strategy like you did.

As we have several large courses (> 2,5GB) I found out that one of the courses took 7 hours to complete (with the cli script via a cron bash script)! And a few others that caused other errors where the automated backup was broken .

I tested your truncate solution of the table mdl_backup_courses and that is also a way to get it working again. But that was not on our production site.

I am looking to implement a solution as you propose, just to exclude the courses that cause all these troubles. 

I hope the next version of Moodle (3.5.x) will have a better implementation of the automated backup process

We have a problem that new courses are not backupped. When I look in table mdl_backup_courses, I don't see the new course id's in the table. Also attribute nextstarttime has different values instead of one value of the automated backup we start at 01:30 hrs at night. We've had some problems with big courses that took too much time to create a backup. We can't exclude them from the automatic backup task. Does the automatic backup stop in case of a course that isn't backupped completely?

Our Moodle version is 3.1.5+

Paul, did you also restore a backup of the database? A change in the database table could cause your problem.

No, we are developing a new theme, that new version caused the problem with the upgrade

I just did, but is that a workaround? What changed in the new version that it's not possible to login anymore?

Update:  I changed my theme to an older theme and then it worked again without the workaround.
This might be a problem in the login page?