The very last step in the backup process ... after moodle_backup.xml is created and the .mbz file is built, is to *copy* the .mbz file to it's destination.
Default desitination is /moodledata/filedir/ sea of files.
So if there is a .mbz file contained in one of those contenthashed named directories,
backups are failing that *copy*.
Check PHP setting for time for a script to run, memory a script can use ...
Might need to bump those values upwards a little.
BTW, dunno what your free space is like, so it is safe to manually remove all
files/folders in moodledata/temp/backup/ as long as autoamted backups isn't running
and no teacher is on the sysetm making a backup.
Still though, the debug indicates (to me at least) there is some activity/resource
in the course that isn't playing nice with backups.
Are you skipping to the end or stepping through the backup screens?
Step through and de-select the HotPot quizzes. Backup finish without errors?
Might have one HotPot quiz causing this.
HotPot has been around for a very long time.
https://moodle.org/plugins/pluginversions.php?plugin=mod_hotpot
Info:
2018-12-08 (32) (2018120832)Moodle 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6
Release date: Saturday, December 8, 2018, 10:38 AM
See the release date ... that was just a week ago.
If you trust me ... have a sandbox instance of a 3.4 and a 3.5 to which you could upload a backup of this troubled course. Doing so would allow me to inspect the .mbz file prior to restoring.
PM me if interested.
'spirit of sharing', Ken