by Ken Task.
In response to this post ... think it's the line above that really counts. During the backup process temp tables are created and are in affect until the routine removes them OR the DB session ends ... ie, on error.
It would be rare, I think, that temp tables are NOT removed when DB session ends.
Back to the previous error:
Stack trace: * line 1194 of /lib/dml/mysqli_native_moodle_database.php: dml_exception thrown
When inspecting the section of code in mysql_native_moodle_database.php where it errored there is this comment:
// MySQL has a relatively small query length limit by default,
// make sure 'max_allowed_packet' in my.cnf is high enough
// if you change the following default...
Normally, when a backup (automated or manual) one sees an error in apache error logs, that says "Server has gone away ..." then other error lines are a result of that. Typically that is directly related to max_allowed_packet setting being to small.
See: https://dev.mysql.com/doc/refman/5.5/en/packet-too-large.html
defaultmax_allowed_packet variable
is 16MB ... increase it to 32MB.
So ... would suggest increasing max_allowed_packet
Locating the course that's causing the issue is somewhat difficult with autobackups. You've declared the destination directory to be outside of filedir and moved all the backups contained therein out to some other location for archiving. Because Moodle couldn't find any file in there, it had to assume, that NO backups have been made. Thus it begins to create a backup for all courses.
In the Moodle Admin UI, there are options/preferences for backups ... the filenames of the backups ... include course ID, shortname. Course ID's begin at 1 ... that's the front page of your Moodle. But from that point forward the CID's are sequential but don't expect to find a '2' IF that course has been removed from the Moodle. Moodle doesn't back fill a course ID number. If CID is deleted, the next CID available is used for the next new course. There might be big gaps in the CID numbers. All that to explain what to look for in the designated diretory. If you know the last course CID is 1190 and one sees CID's in backup filenames up to 1170, then suspect the next course (which could be 1171 or 1180 depending) *is* the problem course that consistently fails backup. Check out that course to see it's contents.
OR use the moodlecode/admin/cli/backup.php script to backup just that course ... like we did earlier with CID 1 (the front page). Did it backup? If not, did you check apache error logs? Is there an php_error file in moodlecode/backup/ that might provide a clue (fastcgi settings for php normally place a php error file in the directory of the script that caused an error.
Do know this from experience ... automated backups correction takes a long time IF one doesn't tweak the time to run, and also set to manual, etc.. Run the CLI script for it. Have seen info Moodle collects on autobackups get so confused that the only way some courses would actually be included in the autobackup was to truncate ALL tables related to the building of/tracking of automated backups. That would result in the same thing that happened when you moved the files in the destination directory to another location. But, now the entries in the various tables are new/fresh and should be correct ... to me, it was easier to spot the troubled course or the area of config that needed to be tweaked.
Sorry for length of this ... it's just a complicated process AND difficult to target the error remotely via forum or via EMail.
'spirit of sharing', Ken