Could be time outs. Check server phpinfo for time for a script to run and memory a script can consume. Might need to bump those higher.
Could be those courses have gotten very large. Check your moodledata/temp/backup/ directory for more than 0 byte log files - those are 'plans' for making course backups which won't make any sense to ya unless you programmed the backup process, but there will also be present directories with long names. Inspect the contents of one of those long directories. If you see a 'backup.mbz' file and a 'moodle_backup.xml' file there it means the process could not finish the very last step which is to copy ... note that's copy ... the backup.mbz file to it's destination according to settings in autobackups. If destination is set to default that is going to try to save in moodledata/filedir/ - nothing in there is humanly readable, so suggest setting up a designated directory for auto backups that you have to create manually with proper ownerships/permisions outside of moodledata.
Easier to archive all those should you get into a space crunch.
Also, set the path to php-cli in paths.
Once that's set correctly, you can navigate to the task list and for automated backups task there will be/should be a 'run now' link. Caution using that run now during prime time and could be that fails due to things mentioned above.
Unforunately, there is no Moodle Admin Tool (other than 'fail delay') in the GUI to clear this pending stuff up so one might have to resort to truncating a moodle DB table that tracks adhoc task remaining in a que.
That table is mdl_task_adhoc. Truncate means you remove the rows from the table ... DO NOT DELETE THE TABLE - remove the rows!
'SoS', Ken