Alain Raap

I just found out while testing in a new environment with a copy of our production site that the automated backup just stops when a corrupted backup is found in the backup directory. This means that the automated backup process is out of sync at that moment. All the courses that are not yet read by the automated backup script remain with the nextstarttime of the last (failed) run. These courses will never be backupped anymore. My backup broke after having read a third part of all courses in mdl_backup_courses. I deleted the corrupted backup, made a new (manual) backup of this course to be sure if I was able to backup this course and uploaded the backup to the map with all the (automated) backups. Tonight I'll see if there's another course in my map that'll cause the automated backup to stop.

This was the error I got at the point the automated backup was prematurely ended (and it said it wasn't possible to read the archive):

!!! Fout bij het verwerken van het archiefbestand !!!

To be sure that all courses will be read by the automated backup script I updated the nextstarttime for all rows in mdl_backup_courses with the date of the next scheduled automated backup run (tonight):

mysql statement: update mdl_backup_courses set nextstarttime = unix_timestamp('2019-03-30 00:00:00');

Jon, we test the upgrade always in a lab environment first. That’s where I got the error. All previous upgrades went smootlhy without problems, but it’s always good to take time to prepare the upgrade to a new version! 

We’re already using the collation that is advised, but two different collations caused my DB error (and I’m not the only one here that got this error). So I had to investigate why I had two different collations on my tables.

Thanks for the link about this DB issue. I think converting the tables with mysql_collation.php script will solve the problem permanently.
And I'll check the 3.5.4 and previous installations if there are different collations used. Probably with Moodle 3.5.5+ this is causing problems with tables that have a different collation then expected.

Thanks for your explanation Ken, my question about why the collation was changed with the upgrade still keeps me busy. I would like to know why the upgrade couldn’t be done without this error. Maybe the next build of Moodle doesn’t give this error, we’ll see.

Well if I upgrade Moodle to a new version I don't expect a database error like this one.

I can't provide the collation, but I compared the collation of all the tables with 3.5.4+ and they were different for several
tables (mdl_user, mdl_config and mdl_config_plugins).

I don't use git, the 'old' way I assume.