GitLab CI Backup

In the previous video we covered the GitLab backup process, and how to copy the created backups of both your GitLab config and your code repos to a remote machine.

In this video we are going to expand upon that process to backup our GitLab CI server.

This guide assumes you are using the GitLab Omnibus edition.

There are a couple of differences to the standard GitLab backup process, one being that we need to run a slightly different backup command:

sudo gitlab-ci-rake backup:create

Notice, this time we are using gitlab-ci-rake instead of gitlab-rake like last time.

That's the first difference.

The second difference is that our GitLab CI backup won't output to the same directory as our standard GitLab backup.

# /etc/gitlab/gitlab.rb

gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

gitlab_ci['backup_path'] = "/var/opt/gitlab/ci-backups"

You can change these paths by editing your /etc/gitlab/gitlab.rb file, but note, they are different by default.

This is important, as if you followed the steps in the previous video, you will need to add in another cron job to pull down the GitLab CI directory also.

Coming From Older Versions of GitLab

If you have had GitLab installed using an older version, the /etc/gitlab/gitlab.rb on your server may not contain all the latest settings.

Whilst GitLab seems to have some sane defaults, where possible I do like to be explicit when setting up a config. Therefore, I would advise to check your /etc/gitlab/gitlab.rb file to see if you have a definition for your GitLab CI backup retention period.

You can see all the available settings for the /etc/gitlab/gitlab.rb file by clicking here. Feel free to copy and paste accordingly. The one we are after here is:

gitlab_ci['backup_keep_time'] = 604800

This tells our GitLab CI backup command to keep our GitLab CI backups locally on disk for 7 days (604800 seconds).

Timing Is Everything

We need to add in a new entry to our root user's crontab on the GitLab server.

This is largely similar to the existing entry we have for our standard GitLab backup:

30 2 * * * /opt/gitlab/bin/gitlab-ci-rake backup:create CRON=1

See the official docs, and / or the notes from the previous video if unsure what's happening here.

I would advise triggering your GitLab CI backup at a slightly staggered time difference from the standard GitLab backup. Thirty minutes apart should be plenty.

If you want to then pull down your GitLab CI backup to your local machine, be sure to add in a new entry on your local crontab, remembering to update the path to the remote ci-backups folder, or whatever path you put in your gitlab_ci['backup_path'] entry:

// linux
rsync -avz --progress root@your-server-ip-address:/var/opt/gitlab/ci-backups /home/your-username/gitlab-ci-backups

// mac
rsync -avz --progress root@your-server-ip-address:/var/opt/gitlab/ci-backups /Users/your-username/gitlab-ci-backups

The rsync command should be clever enough to create the directory on your local machine so that you can write to it, but if unsure, create the local path yourself e.g.:

// linux

// mac

And that should be the basics of how to keep your GitLab and GitLab CI server backed up.


# Title Duration
1 Zero To GitLab in 5 Minutes 05:02
2 Continuously Integrate All The Things 05:10
3 GitLab CI Runner Tutorial 03:04
4 GitLab Reset Password 01:42
5 Updating GitLab and GitLab CI 04:52
6 GitLab Backup 15:56
7 GitLab CI Backup 04:20
8 PHP Continuous Integration with GitLab CI 08:08
9 How To Use VirtualBox as a GitLab CI Test Runner 06:02
10 Running Selenium with Docker During VirtualBox Test Runs 09:02