by Bobby Siegfried.
I'm happy to share about our setup! Our Moodle is connected to our CRM so courses/people/enrollments are all created/updated in real-time. We have an process where we archive courses after the active semester but having them in the same system makes it easy for us to make them available to students when requested and for faculty for a least a year and a half so they can reference and import content from a previous course. That happens a lot and the import is a better option for us for a number of reasons. That being said, of the 18,000+ courses in the system, automated backups only backs up changes which is less than 2,000 courses during a run. That's pretty manageable and works well. But my hesitation for resetting a backup table is simply because I don't want to trigger the system to run fresh backups for every course in the system.
So I took a look at the mdl_backup_courses table and the timestamps were actually all in order, but the laststatus was 0 (which indicates an error). I could manually change that value, but I was unsure if that would actually trigger the backup to restart. I say that because I did some additional research into the mdl_backup_controllers table and found those hashed directory names of each of the failed backups that I cleared from moodledata/temp/backup and each entry had a status of 800 (backup executing).
I'm thinking that if I change the status of 800 to 700 or simply delete those three records from the mdl_backup_controllers table, the process should run successfully again. What do you think?
Also simple little command I was using to show only non-.log files in moodledate/temp/backup: ls -lI *.log (that's a capital 'i' after the -l)
Here is the source I was reading to find more about the status codes: https://github.com/moodle/moodle/blob/MOODLE_37_STABLE/backup/backup.class.php
I'm sure you are aware of all of those, but it's always good to share.
I did check the courses with the bad statuses and they are all average courses, no strange config, not very large. I think it is all just related to the job being killed administratively in the middle of the task running and those courses just happened to be caught in the middle of a backup.
So I took a look at the mdl_backup_courses table and the timestamps were actually all in order, but the laststatus was 0 (which indicates an error). I could manually change that value, but I was unsure if that would actually trigger the backup to restart. I say that because I did some additional research into the mdl_backup_controllers table and found those hashed directory names of each of the failed backups that I cleared from moodledata/temp/backup and each entry had a status of 800 (backup executing).
I'm thinking that if I change the status of 800 to 700 or simply delete those three records from the mdl_backup_controllers table, the process should run successfully again. What do you think?
Also simple little command I was using to show only non-.log files in moodledate/temp/backup: ls -lI *.log (that's a capital 'i' after the -l)
Here is the source I was reading to find more about the status codes: https://github.com/moodle/moodle/blob/MOODLE_37_STABLE/backup/backup.class.php
I'm sure you are aware of all of those, but it's always good to share.
I did check the courses with the bad statuses and they are all average courses, no strange config, not very large. I think it is all just related to the job being killed administratively in the middle of the task running and those courses just happened to be caught in the middle of a backup.