by Ken Task.
Go into the temp directory built for a failed backup ... if you see a directory like:
b12d3b8488ee24a1c730e84540dbbe21it did NOT finish ... the log reaches controller status around 1000 when it does finish and then the log file is cleared ... 0 bytes.
Inspect the directory itself. A finished backup would have a moodle_backup.xml file. And it might have a backup-blah-blah-blah.mbz file actually prsent. If moodle_backup.xml IS not present then the .mbz flie is also not present.
Reason for inspecting the b12... directory ... to possibly see where the backup is failing. 800, 900 references in those logs really don't help much, now do they? The only way (until programmers 'fix' that log and provide little humanly understandable hints for those numbers) is to see where it stopped. Am helping someone else right now with similar issue and in every case, the courses that fail have a rather large number of quizzes and in the activities directory of the temp backup directory we are finding many, many of quiz_#### directories. All of those have a date time stamp. We find the last then we might be able to figure out what quiz in the course to review.
** did you check the task schedules for anything that could possibily conflict ... there is a task to cleanup ... which could mean actually truncating tables related to autobackups/backups at a time when autobackups is running.
Automated backups take it's actions from preferences/options set by site admin ... things like 'don't backup unless there is a change', etc.. So between each automated backup task/cron job the number of courses to be backed up could change. One week ... no changes to some courses should mean they are not backed up by automated backup process (as an example). That means the auto shouldn't take as long as the last time.
Try turning off those task that look like they might conflict with a autobackup process that very well could require many *hours* to complete.
Then there is the number of courses ... how many?
Would suggest, also, sending these backups *NOT* to file area ... which is filedir and in the new file system Moodle runs. Send them to an alternate diretory that you have to create manually somewhere on the system.
In the /report/backups/ of your site, look for failed backups whose dates are messed up ... by that I mean according to the Next scheduled backup time, a backed is schedule a year from now, as an example. See any 'pending'? See in 'errors'? Click the spyglass to see what it might be saying.
Not saying the database is corrupted - in every case I've had to deal with this sort of thing that's NOT been the case, but the info contained therein might NOT be desired OR there was another task or even server process that was creating the issues with autobackups completing.
'spirit of sharing', Ken