The very last step in autobackups is to *copy* the built .mbz file in moodledata/temp/backup/sometempdirectorythatlookslikeahash
to the destintation chosen in config ... destination default is in the sea of files /moodledata/filedir/
If it's just 2 or 3 courses, could be those course backups (if they are indeed built) have gotten so large the *copy* command used to move the built backup.mbz file in the temp build area just times out.
So to see ...
cd /path/to/moodledata/temp/backup/
ls
successful backups leave a 0 byte .log file. Unsuccessful backups leave a .log file with something in it. Those are text files and can be viewed with cat.
What you are looking for, however, are the directories with long names ... change into one of those and ls
If you see a moodle_backup.xml and a backup.mbz file ... guess is it timed out on copy to destination ... the backup.mbz file is a valid backup and can be manually moved to another destination .. not moodledata/filedir/
If you don't see moodle_backup.xml nor the backup.mbz file, nothing in there can be used and should be manually removed but before you do, begin the painful discovery of why.
There should be .xml files that match a directory ... example: files.xml and files directory.
Can't tell you anything specific at this point about poking around in there ... much depends upon what was in the course.
Hopefully your issue isn't running out of space ... but that could also be a cause.
df -h
Sorry ... no fix ....
On one system I had to give up auto backups due to a course reaching 130Gig - could back it up using backup.php script in admin/cli/ with a nohup (it took a couple of hours).
Also had to do a looping bash shell script through course id's and used the cli backup.php script .... had one script for large courses that used the nohup option.
'SoS', Ken