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.
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).
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
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
// 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
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 /home/your-username/gitlab-ci-backups // mac /Users/your-username/gitlab-ci-backups
And that should be the basics of how to keep your GitLab and GitLab CI server backed up.
If you have found this video helpful, please consider sharing. I really appreciate it.
|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|
|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|