Same *exact* error? ... cannot create temp directory ...
Sounds like you still may not have sufficient space.
So what does the command 'df' look like on your system?
Note where moodledata directory is in relationship to the df output.
Disk usage *ballons* in /moodledata/temp/backup/[tempbuildareadir]/
Failed autobackups means the scripts don't know to 'clean up' those tempbuildareadirs and one could have several of those (depending upon the number of courses that would be included according to the preferences chosen in setting up autobackups.
The log files are actually in moodledata/temp/backup/ ...
one will/should see a temp build area for a coruse that consist of a long name of letters and numbers. Something like aslewrjwqero1234fda'vggfhaslsl
There ishould be a corresponding aslewrjwqero1234fda'vggfhaslsl.log file that's larger than 0 bytes. It will be small, however. Those log files are text and one could view them:
But, afraid they won't be much help unless anyone can interpret what is recorded - it shows 'stages' in the 'plan' to create the backup ... you'll see numbers like 100,200,300, etc. Well those stages completed OK. Since it errors, however, one may NOT be able to tell where it died.
More sluthing ... change into the temp build directtory. ... as per example:
A course backup that was at the very last step, that of copying the built backup to destination (which by default unless changed is 'file area' ... ie, filedir in /moodledata/ somewhere) one will see a .mbz file ... along with a moodle_backup.xml (very important file for restoring as it's the roadmap for the backup). That's the point where disk usage is greatest as far as the backup of this one course. The .mbz file IS an archive of all the other files/directories.
A course backup that never reached that stage, one will see NO moodle_backup.xml and no .mbz file. One will see, however, .xml files and their related directories. An example: files.xml and a files directory. IF you see 'matches' then that stage of the backup was possibly succesful.
At this point ... can't tell you anything .... only by study one might be able to figure out where building the backup failed. Checking apache error logs or other logs at this point for the same time might provide a clue.
Other possible pain point ... moodle now has scheduled task ... automated backups is one ... but it also has a task to clean up temp areas. If that task (clean up) didn't for some reason pick up on the fact autobackups was running, it could have executed what it does ... ie, clean up and thus mess up a backup that was being built.
IF, however, you have those long directories (temp build areas) still in moodledata/temp/backup/ and autobackup is no longer running ... nor is any teacher backing up a course ... then it's safe to manually remove everything in moodledata/temp/backup/ Those are failed backups and really can't be used ... and might remain there until the task to clean up kicks in again. It is safe to remove them all ... all directories ... all .log files.
Might use du -h ./ before removing however to get an idea of how much space all that stuff is taking up. Then compare space used with df.
'spirit of sharing', Ken