gitlabバックアップについて

前の記事ではdockerを使用してgitlabサービスを実行する方法について説明しましたが、gitlabのバックアップについて説明します.

方法1

使用するdockerコンテナで実行されるgitlabなので、バックアップを考えると、コンテナのマウントディレクトリを直接コピーしたいのが第一反応かもしれません.しかし、直接コピーしたディレクトリは、別のサーバで直接正常に動作しますか?gitlabコンテナの実行用のデータは確かにマウントディレクトリにあり、理論的には直接使用することができます.しかし、直接コピーにはいくつかの問題があります.gitlabコンテナの実行ログを見ると、データベースアクセス権に関するエラーやredisパラメータの設定などのエラーが見つかります.ディレクトリコピーの過程で、2台のサーバ上の環境が完全に一致しないと、元のサーバ上のgitlab-psqlユーザのuidが996で、所有者がgitlab-psqlユーザのファイルを別のサーバにコピーした後、996のuidは別のユーザに対応し、そのときに権限の問題が報告されます.これらの問題を調べてみると、やはり面倒な感じがします~~

方法2

gitlabに付属のbackupコマンドを使用してバックアップします.gitlabのhelpドキュメントには、URLアドレス:http://your-gitlab-server/help/raketasks/backup_restore.mdgitlabのbackupメカニズムを用いて[TIMESTAMP]_という名前のgitlab_backup.tarのtarファイル.このtarファイルには、すべてのデータベースデータ、すべてのrepoデータ、およびすべての添付ファイルが含まれます.TIMESTAMPは秒単位のタイムスタンプで、1477287208_などの異なるバックアップファイルを区別します.gitlab_backup.tar.なお,backupメカニズムによるバックアップではgitlabのバージョンに対して厳格な一致が要求される.例えば8.6版のgitlabで生成されたバックアップファイルは、8.7版のgitlabで復元され、エラーが報告されます.
(1)backup操作のコマンド

# gitlab ， 
sudo gitlab-rake gitlab:backup:create
# gitlab ， 
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production

バックアップするコンテンツを選択するには、SKIP変数を使用することもできます.SKIP変数のオプションは、db、uploads(attachments)、repositories、builds(CI build output logs)、artifacts(CI build artifacts)、lfs(LFS objects)です.複数のアイテム間をカンマで区切るには、次の手順に従います.

sudo gitlab-rake gitlab:backup:create SKIP=db,uploads

backupコマンドが実行されると、端末にデータベースやrepoデータなどをエクスポートする操作ログが表示されます.
(2)backupの関連配置backupファイルの保存場所はconfig/gitlab.ymlプロファイルに設定します.このプロファイルを開くと、backupに関するこのような構成が見つかります.

  ## Backup settings
  backup:
    path: "/var/opt/gitlab/backups"   # Relative paths are relative to Rails.root (default: tmp/backups/)
    archive_permissions:  # Permissions for the resulting backup.tar file (default: 0600)
    keep_time:    # default: 0 (forever) (in seconds)
    pg_schema:    # default: nil, it means that all schemas will be backed up
    upload:
      # Fog storage connection settings, see http://fog.io/storage/ .
      connection:
      # The remote 'directory' to store your backups. For S3, this would be the bucket name.
      remote_directory:
      multipart_chunk_size:
      encryption:

デフォルトでは、バックアップファイルは/var/opt/gitlab/backupsディレクトリの下に配置され、archive_permissionsプロパティはtarファイルを生成する権限プロパティを指定します.デフォルトは0600です.upload設定でバックアップをリモートサーバにアップロードすることもできますが、詳細はここでは説明しません.
注意:gitlab.ymlにbackupsを配置した後、gitlab-ctl reconfigureコマンドを実行すると、配置されたものが流されていることに気づき、gitlab.rbの中に配置してください.

gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups" # 
gitlab_rails['backup_archive_permissions'] = 0644 # 
gitlab_rails['backup_keep_time'] = 864000  # 10 

(3)backupファイルによるリカバリまず,リカバリに用いるサーバにはbackupファイルと同バージョンのgitlab実行環境が必要である.同じgitlabのdockerミラーを使用しているので、バージョンの一貫性は確保できます.次に、backupのtarファイルがプロファイルで指定した/var/opt/gitlab/backupsディレクトリの下にあることを確認する必要があります.

sudo cp 1393513186_gitlab_backup.tar /var/opt/gitlab/backups/

その後、コマンドとともにリカバリ操作を実行できます.

#  
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq

#  restore ， gitlab 
sudo gitlab-rake gitlab:backup:restore BACKUP=1393513186

#  gitlab
sudo gitlab-ctl start

#  gitlab
sudo gitlab-rake gitlab:check SANITIZE=true

なお、backupで生成するtarファイルのバックアップはgitlabのプロファイルをバックアップしない、gitlab.rb, gitlab.yml,/etc/gitlab/gitlab-secrets.json(two-factor authentication暗号化情報がデータベースに格納されているkey)などのプロファイルは、別途バックアップする必要があります.
(4)バックアップを構成するタイミングタスクcronによるタイミングバックアップ操作

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

バックアップファイルの保存時間を指定したい場合は、/etc/gitlab/gitlab.rbでの構成:

# limit backup lifetime to 7 days - 604800 seconds
gitlab_rails['backup_keep_time'] = 604800