A backup of a Moodle course is a combination of 'files' (those uploaded to a course for use in a course) and entries in tables of the DB - which stores just about everything else. So a backup isn't just a set of files.
Not enough info shared ... adjusting php and FastCGI are two areas, but there is also the DB and it's configuration. During a backup process, the DB is queried for the course content, users in the course, logs, etc. ie, the options chosen to the configuration of backups.
So, Moddle version is key as there has been some additions/changes to the backup process in 2.9 differnt from previous versions (having to do with scheduled task - clean up of the temporary area Moodle uses to create backup files). Check all setting related to backups - are you including logs, users, etc..? Use System Admin menu search box (term 'backup') to find any all parts of Moodle config related to backups.
The area used for creating backups is in moodledata/temp/backup/ A successful backup, regardless of a manual or automated, will leave a 0 byte log file with a contenthashed name. Any .log file that is larger than 0 bytes contains some info. Might be useful clues. Those log files are ASCII and can be viewed with any tool that can view txt files. Check those for clues.
Also in the same area, IF a backup fails, one will find a contenthashed named directory that Moodle was using to build the .mbz backup file. Go into those and see what's there.
IF you see a .mbz file it could be that the backup actually completed but the system couldn't *copy* the .mbz file to the designated area for backups - a setting to check. The little progress bar during a backup ... does it get to like 99% and appears to freeze/stop or take a long time? The last step is to *copy* the .mbz file to destination and that might be the issie - the system cannot copy. But, I've observed that one can manual *move* a .mbz file to another location and inspect it. Valid backup file and could be restored.
File system means the backups are going into moodledata/filedir by contenthashed file names an under the new filing system. Those are hard to locate. Designated directory ... has to exist (admin must created it and give it permissions such that Moodle user can copy files to it. I'd chose that one in this case - makes the .mbz files easier to find.
A key file in the backup area (moodledata/temp/backup/[contenthashnameddir]) is the moodle_backup.xml file. It's the 'roadmap' for the backup ... ie, what's contained in the files directory if it's there and files.xml - the mini-map for files that were contained in the course.
The fact that small courses are failing could indicate other issues. You say there are 3 drives attached but you are un-aware of what's used for what but you didn't mention IF all of those drives actually have free space left. The fact you are using fastcgi and mention drives I have to assume it's means it's Windows. So use what ever tool you have to show the capacity of those drives and usage/freespace, etc. left.
Also check out the setting in php.ini related to temp ... one might find php23kshp files in there that are related to Moodle backups.
Sorry for length of this ... lots to look at and check!
What do you see if you turn on debugging?
'spirit of sharing', Ken