GitLab备份恢复

GitLab备份和恢复

翻译水平有限，如有异议请参照原文 https://docs.gitlab.com/ee/raketasks/backup_restore.html

应用程序数据备份会创建一个备份文档，包含：数据库，所有的代码库和所有的附件。

你可以在一个完全一样版本的Gitlab上恢复你创建的备份

从一个服务器迁移你的代码库最好的办法就是通过备份恢复

备份

GitLab 提供一个简单的命令工具来备份你的整个安装过程，并且非常灵活的满足你的需求

备份时间戳

注意：在GitLab 9.2 时间戳格式从EPOCH_YYYY_MM_DD 更改为EPOCH_YYYY_MM_DD_GitLab version，例如 1493107454_2017_04_25会变为 1493107454_2017_04_25_9.1.0

备份文档会被保存在 backup_path，在config/gitlab.yml中指定。保存的文件名格式为[TIMESTAMP]_gitlab_backup.tar ，TIMESTAMP表示创建备份的时间，加上GitLab的版本号。时间戳对于恢复GitLab和多次备份GitLab是非常有用的。

创建一个GitLab系统的备份

如果是使用的GitLab的集成安装包，使用如下命令：

sudo gitlab-rake gitlab:backup:create

如果你是用源码安装的，使用如下命令：

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

如果你是在一个Docker容器中运行GitLab，你可以这样备份

docker exec -t <container name> gitlab-rake gitlab:backup:create

输出示例：

Dumping database tables:
- Dumping table events... [DONE]
- Dumping table issues... [DONE]
- Dumping table keys... [DONE]
- Dumping table merge_requests... [DONE]
- Dumping table milestones... [DONE]
- Dumping table namespaces... [DONE]
- Dumping table notes... [DONE]
- Dumping table projects... [DONE]
- Dumping table protected_branches... [DONE]
- Dumping table schema_migrations... [DONE]
- Dumping table services... [DONE]
- Dumping table snippets... [DONE]
- Dumping table taggings... [DONE]
- Dumping table tags... [DONE]
- Dumping table users... [DONE]
- Dumping table users_projects... [DONE]
- Dumping table web_hooks... [DONE]
- Dumping table wikis... [DONE]
Dumping repositories:
- Dumping repository abcd... [DONE]
Creating backup archive: $TIMESTAMP_gitlab_backup.tar [DONE]
Deleting tmp directories...[DONE]
Deleting old backups... [SKIPPING]

备份策略选项

Note：在GitLab 8.17 版本时被引入

默认的备份策略是使用Linux命令tar和gzip从各自的数据位置备份基本的数据流。这样可以满足大多数的备份要求，但是在数据迅速的变化时会引起问题。

当tar读取数据正在改变的文件时，错误 ‘file changed as we read it ‘可能会出现，并且会导致备份进程失败。为了解决这个问题，8.17 引入一个新的备份策略：copy。这个策略会在tar和gzip调用前将数据文件拷贝到一个临时的路径，避免出错。

这样的副作用是备份程序会占用1倍的磁盘空间。备份程序会在每次备份前清空临时文件以避免重复，但是这对于较大的安装系统是一个需要考虑的改变。这就是为什么copy策略为什么在8.17不是默认的备份策略。

如果需要使用copy策略来替换默认的数据流备份策略，在备份命令指定参数 STRATEGY=copy。例如：
sudo gitlab-rake gitlab:backup:create STRATEGY=copy

在备份中跳过指定的文件

你可以使用环境变量 SKIP 在备份时指定需要跳过的目录。可用选项如下：

• db (database数据库)
• uploads (attachments附件)
• repositories (Git repositories data Git代码库数据)
• builds (CI job output logs 持续集成输出日志)
• artifacts (CI job artifacts 持续集成项目)
• lfs (LFS objects )
• registry (Container Registry images 注册文件)
• pages (Pages content 目录)

使用逗号,来同时指定多个选项

# use this command if you've installed GitLab with the Omnibus package
# 使用官方集成安装包运行下面命令
sudo gitlab-rake gitlab:backup:create SKIP=db,uploads

# if you've installed GitLab from source
# 如果你使用源码安装的，使用下面命令
sudo -u git -H bundle exec rake gitlab:backup:create SKIP=db,uploads RAILS_ENV=production

上传备份文件到一个远程(云)存储

从GitLab 7.4 开始 你可以让备份程序上传它所创建的’.tar’文件。它使用Fog library来上传。在下面的示例中我们使用AmazonS3 来示例，但是Fog 同样支持其他存储提供商。GitLab同样提供AWS,Google，OpenStack Swift，Rackspace and Aliyun
支持。当然本地存储也是支持的。

对于官方集成包，在/etc/gitlab/gitlab.rb 中添加下面配置：

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-west-1',
  'aws_access_key_id' => 'AKIAKIAKI',
  'aws_secret_access_key' => 'secret123'
  # If using an IAM Profile, leave aws_access_key_id & aws_secret_access_key empty
  # ie. 'aws_access_key_id' => '',
  # 'use_iam_profile' => 'true'
}
gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'

请在编辑完 /etc/gitlab/gitlab.rb 后执行 sudo gitlab-ctl reconfigure 来应用这些配置。

对于源码安装：

backup:
    # snip
    upload:
      # Fog storage connection settings, see http://fog.io/storage/ .
      connection:
        provider: AWS
        region: eu-west-1
        aws_access_key_id: AKIAKIAKI
        aws_secret_access_key: 'secret123'
        # If using an IAM Profile, leave aws_access_key_id & aws_secret_access_key empty
        # ie. aws_access_key_id: ''
        # use_iam_profile: 'true'
      # The remote 'directory' to store your backups. For S3, this would be the bucket name.
      remote_directory: 'my.s3.bucket'
      # Turns on AWS Server-Side Encryption with Amazon S3-Managed Keys for backups, this is optional
      # encryption: 'AES256'
      # Specifies Amazon S3 storage class to use for backups, this is optional
      # storage_class: 'STANDARD'

当你需要上传你的备份到Amazon S3，你应该创建一个受限制的IAM 新用户。为了限制上传用户只有上传备份的权限，添加以下配置到IAM profile配置中，将’my.s3.bucket’替换为你的bucket名。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1412062044000",
      "Effect": "Allow",
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:GetBucketAcl",
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:ListBucketMultipartUploads",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::my.s3.bucket/*"
      ]
    },
    {
      "Sid": "Stmt1412062097000",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "Stmt1412062128000",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my.s3.bucket"
      ]
    }
  ]
}

本地备份

当然你也可以用Fog 提供的本地存储方法 来将备份发送到一个本地挂载设备上(NFS/CIFS/SMB/等.)。使用local_root指定的文件路径必须是git用户拥有的，当挂载时(为CIFS和SMB指定挂载uid为git用户)或执行备份任务的用户(对于集成包是git用户)。

为了local_root必须设置backup_upload_remote_directory参数。这是备份将要被保存的挂载路径的子路径，并且不存在时会被创建。如果你想要把tar包放入挂载路径的根目录，只需要使用’.’来表示即可。

对于集成包：

gitlab_rails['backup_upload_connection'] = {
  :provider => 'Local',
  :local_root => '/mnt/backups'
}

# The directory inside the mounted folder to copy backups to
# Use '.' to store them in the root directory
gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'

源码安装用户：

 backup:
    # snip
    upload:
      # Fog storage connection settings, see http://fog.io/storage/ .
      connection:
        provider: Local
        local_root: '/mnt/backups'
      # The directory inside the mounted folder to copy backups to
      # Use '.' to store them in the root directory
      remote_directory: 'gitlab_backups'

备份文档权限

GitLab默认创建的备份文档(1393513186_2014_02_27_gitlab_backup.tar)权限为owner/group git:git 0600 。这是为了避免其他系统用户读取GitLab用户的数据。如果你需要备份文档拥有不同的权限，你可以使用’archive_permissions’设置。

# In /etc/gitlab/gitlab.rb, for omnibus packages(集成包安装)
gitlab_rails['backup_archive_permissions'] = 0644 # Makes the backup archives world-readable

# In gitlab.yml, for installations from source:(源码安装)
  backup:
    archive_permissions: 0644 # Makes the backup archives world-readable

存储配置文件

请注意备份文件并不会存储你的配置文件。原因之一是你的数据库存储着双向认证的加密信息。在同一个位置存储加密信息和它的key会破坏在第一个地方使用加密的目的！

如果你使用的是集成安装包请参照readme中的说明备份你的配置文件。如果你按照食谱安装，在你的Chef那会有一份配置的备份。如果你是从源码安装，请参照备份你的 config/secrets.yml文件，gitlab.yml文件，SSL keys 和证书，还有你的SSH host keys。

请至少备份你的/etc/gitlab/gitlab.rb 和 /etc/gitlab/gitlab-secrets.json ，或者 /home/git/gitlab/config/secerts.yml (源码安装路径) 来保存数据库对应的加密key。

创建每日定时备份

Note: 下面的cron定时任务并不会备份你的GitLab 配置文件或者SSH host keys。

集成安装用户：

使用root用户创建一个cron定时任务来备份你的代码库和GitLab元数据：

sudo su -
crontab -e

然后，添加下面一行，表示添加一条每天早上2点钟执行备份的定时任务

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

你需要注意的是 backup_keep_time 配置选项只会管理本地的文件。GitLab不会自动的去修剪在第三方存储里的文件，因为git用户不一定有权限去查看和删除文件。我们推荐你在你的第三方存储中配置适当的保留规则。例如，你可以配置Amazon S3 备份策略.

源码安装用户：

cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml # Enable keep_time in the backup section to automatically delete old backups
sudo -u git crontab -e # Edit the crontab for the git user

在最后面添加：

# Create a full backup of the GitLab repositories and SQL database every day at 4am
0 4 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1

‘CRON=1’ 参数告诉备份脚本如果没有发生错误去掉运行输出信息。这是为了减少cron的垃圾信息。

备份恢复

GitLab提供了一个简单的命令接口来备份你的整个安装文件，并且可以很灵活的满足你的需求。

恢复预备这一章节包含了非常重要的信息。试图将GitLab备份恢复实行在生产环境前，请你一定阅读此章，并测试整个恢复过程一次。

请注意：你只能将你的备份恢复到和你创建的备份同一个版本的GitLab，例如：9.1.0。

恢复前准备工作

在执行恢复前，你需要一个正常运行的GitLab。最主要的原因是执行恢复操作的系统用户(git)通常没有创建或者删除数据库的权限，所以需要导入数据进去(‘gitlabhq_production’).所有已存在的数据将会被清空(SQL),或者移动到一个单独的路径中(代码库，上传文件)。

为了恢复一个备份，你还需要恢复’/etc/gitlab/gitlab-secrets.json’(集成包安装)或者’/home/git/gitlab/.secret’(源码安装)。此文件包含了数据库加密键key,CI secret variables, 和 用于双因素认证的secret variables 。如果恢复对应于应用数据备份的加密键文件失败，开启双因素认证的用户和GitLab Runners将会失去对GitLab服务的访问权限。

根据你的实际情况，你可能需要在执行恢复命令时添加一个或者多个参数：

BACKUP=timestamp_of_backup-当存在多个备份文件时需要指定。你可以了解更多关于什么是backup timestamp

force=yes - 在授权keys文件需要更新时选择yes并不再提示

---

源码安装恢复

# 停止连接到数据库的进程
sudo service gitlab stop

bundle exec rake gitlab:backup"restore RAILS_ENV=production

输出示例：

Unpacking backup... [DONE]
Restoring database tables:
-- create_table("events", {:force=>true})
   -> 0.2231s
[...]
- Loading fixture events...[DONE]
- Loading fixture issues...[DONE]
- Loading fixture keys...[SKIPPING]
- Loading fixture merge_requests...[DONE]
- Loading fixture milestones...[DONE]
- Loading fixture namespaces...[DONE]
- Loading fixture notes...[DONE]
- Loading fixture projects...[DONE]
- Loading fixture protected_branches...[SKIPPING]
- Loading fixture schema_migrations...[DONE]
- Loading fixture services...[SKIPPING]
- Loading fixture snippets...[SKIPPING]
- Loading fixture taggings...[SKIPPING]
- Loading fixture tags...[SKIPPING]
- Loading fixture users...[DONE]
- Loading fixture users_projects...[DONE]
- Loading fixture web_hooks...[SKIPPING]
- Loading fixture wikis...[SKIPPING]
Restoring repositories:
- Restoring repository abcd... [DONE]
Deleting tmp directories...[DONE]

---

集成包安装恢复

恢复前你需要：

• 你要安装一个和你创建备份的GitLab绝对一致的版本的GitLab集成安装包
• 你需要执行 `sudo gitlab-ctl reconfigure ·至少一次
• GitLab在运行中，如果没有，sudo gitlab-ctl start 启动它

首先，确认你的备份的tar包文件在gitlab.rb配置文件中 gitlab_rails['backup_path'] 制定的备份路径。默认的备份路径是/var/opt/gitlab/backups。

# 指定备份路径为默认，将备份文件移动到备份路径
sudo cp 1493107454_2017_04_25_9.1.0_gitlab_backup.tar /var/opt/gitlab/backups/

停止连接到数据库的进程。其他的GitLab服务保持运行。

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

下一步，恢复备份，指定你需要恢复的备份文件的时间戳(timestamp)

# This command will overwrite the contents of your GitLab database!
sudo gitlab-rake gitlab:backup:restore BACKUP=1493107454_2017_04_25_9.1.0

重启并检验GitLab

sudo gitlab-ctl start
sudo gitlab-rake gitlab:check SANITIZE=true

如果备份tar文件和你现在安装的GitLab版本有偏差，恢复命令会被一个错误中止。安装正确的GitLab版本并且重试。

---

可供选择的备份策略

如果你的GitLab服务器包含了很多Git库数据，你会发现GitLab自带的备份程序很慢。考虑到这个，你可以考虑使用文件系统快照来作为备份策略的一部分。

示例： Amazon EBS

A GitLab server using omnibus-gitlab hosted on Amazon AWS. An EBS drive containing an ext4 filesystem is mounted at /var/opt/gitlab. In this case you could make an application backup by taking an EBS snapshot. The backup includes all repositories, uploads and Postgres data.

示例： LVM snapshots + rsync

A GitLab server using omnibus-gitlab, with an LVM logical volume mounted at /var/opt/gitlab. Replicating the /var/opt/gitlab directory using rsync would not be reliable because too many files would change while rsync is running. Instead of rsync-ing /var/opt/gitlab, we create a temporary LVM snapshot, which we mount as a read-only filesystem at /mnt/gitlab_backup. Now we can have a longer running rsync job which will create a consistent replica on the remote server. The replica includes all repositories, uploads and Postgres data.

如果你在一个虚拟机上运行GitLab 你也可以创建GitLab服务器的整个VM快照。当然创建VM快照需要你关闭服务器并不常见，所以这个方法或许在实际应用中会被限制。

补充事项

此文档是针对GitLab 社区版和企业版。我们会备份GitLab.com并且确保你的数据安全，请不要用以上方法 导出/备份 你在GitLab.com上的数据。

Issues存储在数据库。他们不能被保存在Git中。为了将你的代码库迁移到另一台升级版本的GitLab上，你可以使用 import rake task 来做批量的代码库导入。注意一旦，如果你是使用导入rake task而不是使用备份恢复，你会有所有的代码库，但是没有任何其他数据。

常见错误

---

集成安装用户在恢复数据备份时输出警告warnings

如果你使用备份恢复程序你可能会遇到下面的警告：

psql:/var/opt/gitlab/backups/db/database.sql:22: ERROR:  must be owner of extension plpgsql
psql:/var/opt/gitlab/backups/db/database.sql:2931: WARNING:  no privileges could be revoked for "public" (two occurrences)
psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING:  no privileges were granted for "public" (two occurrences)

请注意，备份已经忽略这些警告成功恢复了。

rask任务以gitlab用户运行，但是没有对数据库的超级管理员权限。当恢复过程以gitlab用户初始化时会同时尝试修改没有权限访问的对象。这些对象对于数据备份恢复除了烦人的警告没有其他影响。

想要了解更多pgsql上的相似错误可以访问这里和这里 当然还有 stack overflow。