When I try and restore a backup, I get an error:

cd backup-utils/bin
./ghe-restore my-debug-server.mycompany.com
Checking for leaked keys in the backup snapshot that is being restored ...
* No leaked keys found
Connect ############################:122 OK (v2.19.6)

WARNING: All data on GitHub Enterprise appliance ############################ (v2.19.6)
         will be overwritten with data from snapshot 20200228T031511.
Please verify that this is the correct restore host before continuing.
Type 'yes' to continue: yes

Starting restore of ########################:122 with backup-utils v2.19.1 from snapshot 20200228T031511
/home/github/backup-utils/share/github-backup-utils/bm.sh: line 54: /mnt/github-backup/production/20200228T031511/benchmarks/benchmark.20200228T104648.log: Permission denied
Warning: storing backup-utils version remotely failed.
Stopping cron and github-timerd ...
Restoring UUID ...
Restoring MySQL database ...
/home/github/backup-utils/share/github-backup-utils/bm.sh: line 54: /mnt/github-backup/production/20200228T031511/benchmarks/benchmark.20200228T104648.log: Permission denied

It seems that because the docker container is creating all the files and folders as 755 root:root and my user github is not a member of root that I could not write to the folder and the restore fails.

I think I have fixed the issue with sudo chmod g+s production and then making all the folders in that path owned by the github group.

This was not obvious, took quite a while to find as a solution and still meant I had to retrospectively chgrp the entire backup folder which takes a long while. I am also not sure it is enough as the default is 755 not 775 and in an effort to discover if the backups are valid simply did chmod -r 775 current, which also takes a long while.

Am I doing something wrong?
Should I just be running the restore as root?
Should I be running the restore using your docker container?