Know about 'rabbit holes' ... been down in them ... have inadvertently directed folks in attempts to assist into them (not meaning to - later discovered bits of information not shared initially ... like SELinux on a RHEL box set to enforcing). So I can't say I have the 'perfect' answer, but have discovered what works best for me and the clients I assist (not a Moodle Partner).
Virtual apaches on the same physical machine using the same MariaDB, PHP, Apache versions/configs has same CPU limitations is under the same operating system, etc..... one host dev.FQDN.net and the other prod.FQDN.net. It's the same environment then for sure.
Are both environments (the dev and the production) the same as shown in the chart? Not shown are things like memory, if system is using swap space already, how many CPU's etc.. Are they both RedHat EL6? and are the configs for PHP, MySQL, httpd the same?
A version 2.7.9 of Moodle, even it the versions of PHP, MySQL/MariaDB, OS are the same, on a box that has 2 Gig memory vs a box that has 24Gig memory would/might perform differently.
All that to say, there's more than meets the eye to such issues.
The courses themselves might dictate an increase in max_files_open settings in MariaDB upon restoring or an increase in the extra memory PHP can allocate, for examples. While the size of the .mbz backup file is sometimes an indication of what to expect, back file size can be deceiving IF the course has a large number of quizzes/question bank or assignments that were created with the old assignment mod and haven't been converted to new. .... etc.. Those are examples ... not necessarily the cause of what you are experiencing.
I use true file system repositories in the dev virtual apache site to do automated backups of courses to alternate location (I can then see the humanly recognizable file names and manipulate them without having to fool around with the "new file system') and then use symlinked file system repos in the prod virtual apache to be able to see those backups to restore them. No download/upload etc..
Having the ability to copy the backup .mbz files out into a test directory to be able to inspect troublesome restores to prod has been beneficial - without having to download, etc..
Wish there was one simple answer that fits all ... but think there isn't such a thing with un-known variables. :\
'spirit of sharing', Ken