Sounds like debugging needs to be turned on. Then try whatever process.
When files are removed from the new file system they are actually tagged as 'trash' and remain in /moodledata/trashdir for the default of 4 days. Only the cron job empties the trash. Run cron from browser more than once to see if there are any references (towards the bottom of cron output) for emptying the trash ... ie, actually deleting those files.
Also check your logs ... apache error logs and mysql log if ya have access to it (or if your mysql is actually logging).
Check your moodledata/temp/backup/ directory. Moodle uses that directory for course restores and it's where .mbz files get 'unzipped'. You might find files of 0 bytes ... with long names:
20208a0a786fe22ab01a2ebb1cc99cbf.log
that's normal and indicates successful whatever.
However, you might also see directories or files with long names like:
d135674680f61bc70d6c627a117d7be8
Those are either backups/restores in progress or failed backups/restores
If it's a file: file -b d135674680f61bc70d6c627a117d7be8 will show the file type.
Zip archive data, at least v2.0 to extract
it's a zip!!!
unzip -l d135674680f61bc70d6c627a117d7be8
will list the contents.
unzip -j 'd135674680f61bc70d6c627a117d7be8' 'moodle_backup.xml' -d './'
will extract just the moodle_backup.xml file which is a 'map' of the contents of the backup.
head -n 10 moodle_backup.xml
will show the first 10 lines of that xml file and give info that might be useful.
In restoring 2 backups have found that max_packet_allowed had to be increased (500M?) as well as open_files_limit (6000?) in MySQL. Those (values) a guess.
'spirit of sharing', Ken