Allow restoring a specific backup with server-side backups
What does this MR do and why?
Pass through the backup ID to gitaly-backup so that specific backups can be restored for server-side backups. The backup ID is still ignored when restoring non-server-side backups.
How to set up and validate locally
- Enable server-side backups in gdk.yml:
object_store: enabled: true
- Rejigger gdk:
$ gdk reconfigure && gdk restart
- Make sure minio has a bucket called
gitaly-backups
. Visit http://127.0.0.1:9000 user:minio
, pass:gdk-minio
. - Create a full backup with REPOSITORIES_SERVER_SIDE=true. Skip db to be less invasive and faster.
$ bundle exec rake gitlab:backup:create SKIP=db REPOSITORIES_SERVER_SIDE=true ... 2023-10-02 22:48:41 UTC -- Backup 1696286904_2023_10_02_16.5.0-pre is done. 2023-10-02 22:48:41 UTC -- Deleting backup and restore PID file ... done
- Make some obvious changes to a repository. We'll use this to determine if the previous backup was restored or the backup we're about to create.
- Create another full backup with REPOSITORIES_SERVER_SIDE=true. Note the different backup ID.
$ bundle exec rake gitlab:backup:create SKIP=db REPOSITORIES_SERVER_SIDE=true ... 2023-10-02 22:54:58 UTC -- Backup 1696287282_2023_10_02_16.5.0-pre is done. 2023-10-02 22:54:58 UTC -- Deleting backup and restore PID file ... done
- We now have two different backups. In this example the first
1696286904_2023_10_02_16.5.0-pre
and the second1696287282_2023_10_02_16.5.0-pre
. We should be able to restore the first and the obvious changes go away, then restore the second and the obvious changes come back.$ bundle exec rake gitlab:backup:restore BACKUP=1696286904_2023_10_02_16.5.0-pre ...
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by James Fargher