This part ...
"changed the extenssion from .zip to .mbz and they restore successfully (no I am not all goofy and happy that this change of file extension made it work work and I know there is corruptions and problems by just doing things like this, but that is the purpose of a test environment right?"
A .mbz is a .zip by another name:
If you have a .mbz file on the Ubuntu server, one could get brief file info by:
file -b nameofmbzfiles.mbz
The restore process unzips .mbz's or .zip into moodledata/temp/backup/
Changing the extension doesn't, however, actually change the key .xml file Moodle uses to restore courses and their contents.
In a 1.9 backup, that file is called moodle.xml and it must reside a the root of the extraction.
In a 2.x backup. that file is called moodle_backup.xml ... ditto on location when extracted.
The other key .xml file is called users.xml. IF there are users in a backup.
So *if* did get users into the newer moodle their preferences/settings, etc. might be frapped up and some how, some way, a flag is set in the DB so that all of them get notifications. In affect, you've in-adavertently created your own 'spam' issue.
Since it's a test site ... remove all users who are students.
Using bulk upload, create some students via csv file. Or just manually create a couple of more hpotters ... hpotter1, hpotter2, etc.. as students.
Assign those students to some courses, run your cron job and let's see what happens!
Those notification messages shouldn't be sent to those hpotter1 users ... but if message attempts are sent to them they would bounce because they do NOT exist in your true Mail server.
Mail server logs would/should show that.
Gonna have to cut this one loose cause of the 'non-standard' way of doing things there is probably no way another person could replicate your problem. But continue to 'play' in your sandbox! But know that no one here on these forums may be able to help. At least you're learning what works and what doesn't! ;)
'spirit of sharing', Ken