The attached moodle_backup.xml is complete.
And if you have a .mbz file in that temp directory am almost willing to bet it's a valid/good backup file.
The last things moodle attempts to do is *copy* the .mbz file to destination ... which could be /moodledata/filedir/ and clean up those temp tables.
Back to the original error posting ... see:
moodle_temptables.php
moodle_temptables->dispose()
drop_table(Object(xmldb_table))
Those indicate trying to remove a temp table.
So suggest changing the db user and db password in config.php to the superuser and superuser password.
The user currently in config.php might not have priv's to do things like dropping temp tables.
BTW, your use of the term 'module' really doesn't equate directly to the way moodle makes backups
Take for example this entry in moodle_backup.xml
<setting>
<level>activity</level>
<activity>scorm_1940</activity>
<name>scorm_1940_included</name>
<value>1</value>
</setting>
If you put your mouse over the SCORM link it should show an ID number.
If you had your mouse over the SCORM linked to the 1940 SCORM it would show:
yoursite/mod/scorm/view.php?id=1940
So if using superuser creds don't fix this, you need to backup the course multiple times noting which SCORM link (module in your terms, I guess) caused the backup to fail. There's your culprit.
'spirit of sharing', Ken