Well, then provider needs to update their web pages ... that said they offer MySQL 5.1
For 2.9 Moodle recommends MySQL 5.5.31:
https://download.moodle.org/releases/security/
The environmental checks code can be hacked to hide skip thus not error certain requirements ... like that of the version of MySQL recommended by Moodle HQ. Am not saying your provider did that, but ....
Those 4KB files indicate failed backups. They have 'contenthash' file names .... ie, a bunch of letters and numbers and have extension of .log. They are text/asciii. If you could, open one of them to see what it says inside. Think they might show the stages (plan) by an ID number ... 100, 200, etc. If that log gets to something like 800 (sure would be nice if program would use a single word to indicate what those numbers mean) see below:
The fact backups get to 96.4% is significant. The very last thing the backup process does is 'copy' the built backup.mbz file to it's destination according to choices/options OP (ie, you) has chosen. THe default it to save the backup in the 'file area' (moodledata/filedir/) in an obscured fashion (contenthash named - not humanly recognizable). Many systems that are under-powered fail at 'copy'. If one had command line access, however, one can 'move' a backup.mbz file to a location outside of moodledata/filedir/. It sounds like the package you have purchased on a shared system (might be very affordable - saw they offer $2.95 a month but generally means there are caps/restrictions really unknown to customers, until they try to run something, like a Moodle, that pushes over those caps/restrictions.
In your version of Moodle (2.9.x), Site Admin, Courses, Backups, General Backup defaults, one could select items to backup or deselect. Since this course has been used a lot, suggest unchecking some items in that list and exclude things to get a minimum backup ... exclude users, exclude logs, etc. Goal is to reduce the backup and thus the processing required to back the course up. Am assuming we want a course backup that could be restored like a fresh course. If the logs for this course have never been reduced, that could possibly lead to issues with the amount of data contained therein.
There is also something new called 'task' which is like a laundry list for cron jobs broken out There's one for Clean backup tables and logs That should be off for now. You might need to turn it back on after this issue is resolved.
You can check on versions of things ... Site Admin -> Server -> PHP Info will show not only php version, but things like Operating system - the first line in the info displayed.
'spirit of sharing', Ken