How do I get the name of the backup file when using gitlab-backup?

My Setup:
Ubuntu 22.04 (hosted public vm)
GitLab Community Edition v16.4.0

I’m attempting to create a script to backup our GitLab server. I was testing the gitlab-backup command and it created these files:


I want to grab this filename in my script so that I can upload it to our ftp server. Is there a way to specify the complete name instead of the partial name or how would I grab this filename after this runs:

gitlab-backup create

Thanks for the help!

Assuming that the date is consisent, you can do something like this:

Set a variable in the script, using:

date '+%F'

would give 2023-10-12, but we can modify that, by doing this:

date '+%F' | sed 's/-/_/'

which then gives us 2023_10_12 to match what is in the filename (as per your example). This will now match the filename created in /var/opt/gitlab/backups. So you could do this in the script:

BACKUP_DATE=`date '+%F' | sed 's/-/_/'`
BACKUP_FILES=`ls /var/opt/gitlab/backups | grep ${BACKUP_DATE}`
  cp /var/opt/gitlab/backups/${FILE} /backups

I’ve used cp here just to finish off the loop, but you can adapt this to use ftp, rsync or whatever based on that.

Great info! tyvm!

One last question, if the backup didn’t work, wouldn’t this be grabbing the wrong file, or rather an old file?

Thanks again!

If a backup doesn’t exist for the date in question it won’t do anything. We are using the backup date to filter the files in the backup directory. So if it greps the date of the backup and nothing is there, nothing will be copied/ftp’d/rsync’d.

If it partially backs up and creates files, or some parts of backup fails or aren’t included in the backup file, then yes, you may not have a consistent backup. But you should be monitoring this anyway by checking log files, backup file sizes, etc, to ensure that the backups worked each day or however often they run. You never ever assume that a backup worked by not checking it every so often.

I even do a restore every six months or so, to ensure I can recover my systems in the event of a failure - a good way to check/test that the backups are good, and that the restore procedures for recovery work.