@erika alarcon
Don't think so.
But ...
Got command line access to server?
In code/admin/cli/ there is a restore_backup.php script
Help on that:
Restore backup into provided category or course.
If courseid is set, course module/s will be added into the course.
Options:
-f, --file=STRING Path to the backup file.
-c, --categoryid=INT ID of the course category to restore to. This option is ignored when restoring an activity and courseid is set.
-C, --courseid=INT ID of the course to restore to. This option is ignored when restoring a course and the categoryid is set.
-s, --showdebugging Show developer level debugging information
-h, --help Print out this help.
Example:
$sudo -u www-data /usr/bin/php admin/cli/restore_backup.php --file=/path/to/backup/coursebackup.mbz --categoryid=1
$sudo -u www-data /usr/bin/php admin/cli/restore_backup.php --file=/path/to/backup/activitybackup.mbz --courseid=1
Advantage in using ... web server,WAF,php limits (timeouts) etc. not in the loop. Just php-cli talking to DB.
Plus if you have a very large mbz file can put the command in a no hang up wrapper and it will run forever
nohup command & [ENTER]
Starts the command and a nohup.out log at same location then exits back to the shell. You could then log out ... come back later to check on progress by
cd /path/to/moodle/admin/cli/
tail -f nohup.out
Or explore moodledata/temp/backup/ area for new directories and watch those.
BTW, failed restores will leave junk in moodledata/temp/backup/
Cron job has a cleanup task ... but I've had to manually remove any/ all that is in that directory to reclaim disk space before.
'SoS', Ken