Gitlab Backup and Restore

backup of a working Gitlab and restore

Table of contents

How to take a backup of a working Gitlab and restore it

backup prerequisites

  • Make sure the version is the same in both Gitlab and the backfile generated

Backup

For GitLab 12.2 or later:

sudo gitlab-backup create

This creates a .tar file with UNIX time and the GitLab version filename. Now you can transfer this file for restoration. We can use SFTP, rsync, or an S3 bucket for transferring. If you have configured an IAM role to backup to S3, by running this command, it automatically uploads the backup file to S3.

Restore prerequisites

  • To restore a backup, you must restore /etc/gitlab/gitlab-secrets.json (for Omnibus packages) or /home/git/gitlab/.secret (for installations from source). This file contains the database encryption key, CI/CD variables, and variables used for two-factor authentication. If you fail to restore this encryption key file along with the application data backup, users with two-factor authentication enabled and GitLab Runner loses access to your GitLab server.

This procedure assumes that:

  • You have installed the exact same version and type (CE/EE) of GitLab Omnibus with which the backup was created.
  • You have run sudo gitlab-ctl reconfigure at least once.
  • GitLab is running. If not, start it using sudo gitlab-ctl start.

Restore

First ensure your backup tar file is in the backup directory described in the gitlab.rb configuration gitlab_rails['backup_path']. The default is /var/opt/gitlab/backups. It needs to be owned by the git user.CopyCopy

sudo cp 16493107454_2022_04_25_14.6.1-ee_gitlab_backup.tar /var/opt/gitlab/backups/
sudo chown git:git /var/opt/gitlab/backups/16493107454_2022_04_25_14.6.1-ee_gitlab_backup.tar

Stop the processes that are connected to the database. Leave the rest of GitLab running:CopyCopy

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# Verify
sudo gitlab-ctl status

Next, restore the backup, specifying the timestamp of the backup you wish to restore:

# This command will overwrite the contents of your GitLab database! sudo gitlab-backup restore BACKUP=16493107454_2022_04_25_14.6.1-ee

If there’s a GitLab version mismatch between your backup tar file and the installed version of GitLab, the restore command aborts with an error message. Install the correct GitLab version, and then try again.

Next, restore /etc/gitlab/gitlab-secrets.json if necessary, as previously mentioned.

Reconfigure, restart and check GitLab:CopyCopy

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true

backup prerequisites

  • Make sure the version is the same in both Gitlab and the backfile generated

Backup

For GitLab 12.2 or later:

sudo gitlab-backup create

This creates a .tar file with UNIX time and gitlab version filename. now you can transfer this file for restoring. we can use sftp, rsync, or s3 bucket for transfering. If you have configured IAM role to backup to S3, by running this command it automatically uploads the backup file to S3.

Restore prerequisites

  • To restore a backup, you must restore /etc/gitlab/gitlab-secrets.json (for Omnibus packages) or /home/git/gitlab/.secret (for installations from source). This file contains the database encryption key, CI/CD variables, and variables used for two-factor authentication. If you fail to restore this encryption key file along with the application data backup, users with two-factor authentication enabled and GitLab Runner loses access to your GitLab server.

This procedure assumes that:

  • You have installed the exact same version and type (CE/EE) of GitLab Omnibus with which the backup was created.
  • You have run sudo gitlab-ctl reconfigure at least once.
  • GitLab is running. If not, start it using sudo gitlab-ctl start.

Restore

First, ensure your backup tar file is in the backup directory described in the gitlab.rb configuration gitlab_rails['backup_path']. The default is /var/opt/gitlab/backups. It needs to be owned by the git user.CopyCopy

sudo cp 16493107454_2022_04_25_14.6.1-ee_gitlab_backup.tar /var/opt/gitlab/backups/
sudo chown git:git /var/opt/gitlab/backups/16493107454_2022_04_25_14.6.1-ee_gitlab_backup.tar

Stop the processes that are connected to the database. Leave the rest of GitLab running:CopyCopy

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# Verify
sudo gitlab-ctl status

Next, restore the backup, specifying the timestamp of the backup you wish to restore:

# This command will overwrite the contents of your GitLab database! sudo gitlab-backup restore BACKUP=16493107454_2022_04_25_14.6.1-ee

If there’s a GitLab version mismatch between your backup tar file and the installed version of GitLab, the restore command aborts with an error message. Install the correct GitLab version, and then try again.

Next, restore /etc/gitlab/gitlab-secrets.json if necessary, as previously mentioned.

Reconfigure, restart and check GitLab:CopyCopy

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true

Tags: , ,

Leave a Reply