Part 2 ...
In the report of automated backups, check the dates ... especially the next run date. Had a system once that recorded the next run date that was already past ... would have been a year for that course to catch up. That one course was the largest course (90Gig) and affectively killed the automatted backup process every time auto backups ran.
Check task for clean ups of that directory ... task might be kicking in cleaning up a backup that's being built.
Check (manually) what's in moodledata/temp/backup/
Successful backups leave a 0 byte .log file. Un-successful backups leave a .log file with info in it. You can cat those larger then 0 byte .log files to see what Moodle might be complaining about.
The process can do only one backup at a time .... creates a build directory with long combo of letters/numbers.
IF you have more than one of those directories ... they could contain failed backups and worth the time to explore via command line.
IF one finds a .mbz file contained therein, the backup of that course failed at the last step which uses a 'copy' routine to place the backup file in destination. That could be in moodledata/filedir/
Those are good backups ... ie, can be restored ... they just couldn't be copied to destination ...
Think in CentOS, as an example, if the backup is over 4 Gig in size copy struggles/fails ... kernel thang.
I'd keep automated backups out of moodledata/filedir ... reasons ... saved to another destination directory one can easily find them to archive off the server or remove if you needed space and, obviously, easier to find/see if certain courses have been backed up as well as the number of backups for a course.
Which leads to this .... how many copies are you keeping? That's a setting in autobackups.
One can manually remove all files/folders in moodledata/temp/backup/ with no ill affects .... cept if you do that when a teacher is backing up a course.
You might have to restort to truncating all tables related to autobackups ... there are three ... that won't remove the backups that have been created ... but it would help in the scheduling/timing of the next next run.
You also might have to resort to your own home-grown scripts to autobackup large courses (like the moosh script to find course info) and then another script to autobackup all the other courses that will complete in a reasonable time.
I do have one server where I've had to resort to that - have 3 multimedia courses that get huge throughout the academic year and they require a separate script to backup ... on a weekend - Sunday early AM. The other script gets all the rest of the courses on Wed. (early AM) and it does complete in a couple of hours time.
Would be a nice option to check off which courses to include in automated backups ... or exclude for admin to handle another way ... and has been discussed/maybe eveh proposed ... but it never seems to get much priority.
This doesn't pin point as to why auto backups fail ... more a guide on what to look for ... every system is different.
'spirit of sharing', Ken