@sandy I imagine even across the network the act of transferring the DB would not take very long at all, maybe a minute at the most if your network is modern at all. I would consider doing local backups on the server, then a second process via cron etc. to transfer the backups from the server to a separate location via rsync.

Restoring takes into consideration the size of the DB as well as the resources of the db server itself, so the more resources on the server the more likely that the restore would be faster. If this was a VM you might be able to look at the resources of the server and see if you had high memory/cpu utilization during the time you did the restore.

@ryan.ball Thanks, I did not have any issues and all is well.
Some of our services are in transition but this is working fine, as is, for now
Since the utility shows no progress bar and I found no posts with completion estimates I just thought it would be nice for the next person to know my experience.
As you know, backing up using the utility also scans and repairs the DB so that is included in the time from when the job kicks off to backup complete.

Something wrong with mine then mysql 8.0 java 14, JAMF Pro 10.14 just over 1gb backup, fails on restore at present we dont have a working JAMF pro as we cant restore databse, got ticket open but going nowhere fast.

deleted

@conitsupport What version of Jamf? What error is it throwing? Ran into an issue where I had to increase the max_allowed_packet count inside the Jamf Tools to allow my DB backup to restore.

this highly depends on a few things. Mostly the uncompressed size of your database and your db server specs. I am not too familiar with what the jamf tools do either out of the box. They could be running some sort of verify or the backup as it is restoring. You can test just "plain vanilla" back up and restore options using mysqldump to get some benchmarks.

Otherwise, so much depends on so many factors