There is a hidden admin tool to check 'health - via browser:
site/admin/tool/health/
Run that. One of things it checks is the health of quizzes.
Restores have to un-compress backups in moodledata/temp/backup/ and then moodle uses moodle_backup.xml as the major road map to restore. Other xml files ... like files.xml relate to the files directory contained therein. If you don't see moodle_backup.xml in those directories, no map ... no workie!
The only thing that should remain in moodledata/temp/backup/ are 0 byte .log fiiles on successful backups and restores. Any .log file larger than that has where the backup/restore failed ... executing a plan - plan levels give you a clue as to failure - if one can figure out those plan levels!
Any directory you find in moodledata/temp/backup/ is a failed backup/restore ... see what is in them via file browser.
What is your setting for max_input_vars - might want to bump that up if @ 5000 or below. Other php setting you might want to bump up ... time for a script to run, memory a script can consume. Changing any means you must restart web service for those changes to be in affect.
Do you have autobackups turned on an scheduled? If so, might want to turn that off until resolved.
Do you have command line access to server?
There is a backup.php script in code/admin/cli/. That takes web service out of the loop and one has a destination option to the command. It still uses backup preferences for what to include in the backup. There is also a restore_backup.php script located there. Might give that a shot.
And that's something else to check - if the courses have been used for a long time, their event logs might be rather large - event logs are the 'who done it' for that course. Since you are attempting to restore to a new course, you don't need those events.
No real science to this ... just more digging and scratching head!
'SoS', Ken