In moodledata/temp/backup/ 0 byte log files are the remains of backups that completed successfully. Any folder that has a content type hash name ... long ... several letters and numbers, are either course backups being performed or ones that failed.
Inside those, there *could* be a file 'backup.mbz' that is a valid backup, but, for some reason, the routine could not finish the last step ... which is to *copy* the backup.mbz file to it's destination (by preferences set by admin user). Noitce that's copy and not move. So for a little bit there, space usage for such a backup is responsible for a ballon in usage of space.
I have found, in the past, those backup.mbz files are good and could be used to restore that course.
Also, a finished backup, there will be a moodle_backup.xml present which is the roadmap for the content of that course. Also present, a files folder with corresponding files.xml (the map for files). Also a questions.xml ... which, if course had a lot of quizzes/test is probably the entire quiz bank - and usually large.
The tuff part of figuring things out with a backup of that troubled course is, of course, what failed or what is taking so long. No science to that ... just a lot more sluething by visiting the course via UX to see what might be causing.
Things that could affect ... max_packets_allowed, php timings/settings ... time for a script to finish, memory a script can consume, etc.
If there is already one backup of that course, might have to copy that to a test area and un-archive it to see what's in it!
BTW, I've had greater success in breaking apart autobackups into 3 scripts and using command line scripts to backup groups of them ... small, medium, large. The large ones were 100G+ ... one was 130G ... and they were done only once a week on weekends in the wee hours of the AM - non-prime time. It did take about a week to sort things out and getting backups working again.
Good luck!
'SoS', Ken