If I re-call correctly, at one time you had some issues with upgrading the site and had kinda worked your way through that in a non-standard way. So I think what we have here is a data directory (filedir folder in particular) that doesn't have files the DB mdl_files table says it's supposed to have. No wonder backups (of any kind) are failing.
The hashnamed directory in moodledata/temp/backup/ is the place Moodle uses to build the contents of a course into a .mbz (a zip) file. It uses/builds xml files as 'maps' (if you look at files.xml in particular, you will see references to contenthash named files in diretories of the 'files' folder in this area) etc., etc.
The 6ae.... file appears to be a 1.7M backup that may have completed but didn't get moved back into /moodledata/filedir/6a/e....
In it's present state, it's of really no use to you. But, you could change that filename to 'somebackup.zip', download to your local machine and inspect, if you desire.
You *can* safely remove any all files/folders in moodledata/temp/backup/ ** however, before you do that, you might use at least the information in the files.xml file (humanly recognizable file names) as a guide as to which records to delete in your data base - mdl_files table.
Let's take one of those missing above ... Dragster_Image_1.jpg
Do a query on your DB:
select * from `mdl_files` where `filename` like "Dragster_Image_1.jpg"
There might be more than one reference to that file in the table, but we are interested in finding IF that file does indeed exist in /moodledata/filedir/
In the contenthash field of what is returned to you by the query above.
It might something like this but not exactly (the following is an example):
b6bd31d7d12f5d1b1e0d26957529efa2f71a3
take the first two characters (b6) and see if there is a folder (b6) in /moodledata/filedir/. If there is see if there is (taking the second 2 characters of the contenthash info) a bd folder in b6.
From the command line (see attached for graphical view):
[root@sos filedir]# ls b6
9a bd
ls list files and as you can see there is a 'bd' in that directory. Listing files in b6/bd/ shows a file ... notice it is named the same as the contenthash info in the DB.
[root@sos filedir]# ls b6/bd/
b6bd31d7d12f5d1b1e0d26957529efa2f71a3646
Attached screen capture illustrates. The following command on a Linux server does provide information about that file as well:
[root@sos bd]# file -b b6bd31d7d12f5d1b1e0d26957529efa2f71a3646
JPEG image data, JFIF standard 1.01
** IF you don't find those subfolders nor a contenthash named file (which is Dragster_Image_1.jpg) would think it safe to remove the row(s) that refer to that graphic in the mdl_files table of the DB.
I know you're gonna wanna 'easy button' (some 'magic wand' mysql command that will clear it all up), but don't think there is one in this case.
*** But, at least this appears to be limited to one course. *** and that's a good thing.
This situation really does illustrate that in version 2 of Moodle the data directories filedir folder is key when migrating/moving/upgrading and contents therein *MUST* match references in the DB.
In this case, since the file (hashnamed) is not here, the empty trash routine cannot find physical files to move to trashdir and empty and backups of courses that might have broken links to those files can't complete ... can't find the hashnamed file to include in the backup.
'spirit of sharing', Ken