GitLab备份|相同信息的不同归档校验和

时间:2017-10-27 13:34:09

标签: backup gitlab checksum gitlab-omnibus

摘要

当我创建GitLab的备份时。我总是有不同的校验和。

重现的步骤

sudo gitlab-rake gitlab:backup:创建STRATEGY = copy

目前的错误是什么

我创建了备份脚本,每小时备份一次GitLab并在云存储中发送存档。 在两个内容相同的档案中,总有一个不同的校验和。 为什么我有两个具有相同文件和相同校验和的文件夹,但是当这个文件夹存档时,我会得到不同的校验和?内容没有改变,但校验和总是发生变化。为什么呢?

预期的正确行为是什么?

如果未编辑存档,则必须具有相同的校验和

相关日志和/或屏幕截图

94e779cbe595eda6f79f15437d6059ec50c40de9efe01c7c8227b2c799556aac  artifacts.tar.gz (first)

a15da160a4bc6d308f47bd0ebbbeaa09c549f07136d6f13203f05cf0374c77d2  569.log
709b40d737572628d282d5c5f97a62ea4681560d3300f5c126d34436a375618d  570.log
caf0c823c22213c63a86299c4100aec8e8913d3ef6209d36e893982d6fdf3510  571.log
dc77e18335dde4e2ba3ac38d4b2c8b9f59785057e871cceaea172596d3932a0c  572.log
709b40d737572628d282d5c5f97a62ea4681560d3300f5c126d34436a375618d  573.log
14ec475a0cbfc50408a010e14c7f5ab91ae4f675046b53b0e4a65d5dec7e2b79  574.log

67fbe4206bc4b2e5298472e155b81643fb8a30ab41b3c7971e2c9c9c0af1d9a7  artifacts.tar.gz (second)

a15da160a4bc6d308f47bd0ebbbeaa09c549f07136d6f13203f05cf0374c77d2  569.log
709b40d737572628d282d5c5f97a62ea4681560d3300f5c126d34436a375618d  570.log
caf0c823c22213c63a86299c4100aec8e8913d3ef6209d36e893982d6fdf3510  571.log
dc77e18335dde4e2ba3ac38d4b2c8b9f59785057e871cceaea172596d3932a0c  572.log
709b40d737572628d282d5c5f97a62ea4681560d3300f5c126d34436a375618d  573.log
14ec475a0cbfc50408a010e14c7f5ab91ae4f675046b53b0e4a65d5dec7e2b79  574.log

支票输出

此错误发生在GitLab-CE Omnibus

GitLab环境信息的结果

(对于使用omnibus-gitlab包的安装,运行并粘贴以下输出: sudo gitlab-rake gitlab:env:info)

System information
System:     Ubuntu 16.04
Current User:   git
Using RVM:  no
Ruby Version:   2.3.5p376
Gem Version:    2.6.13
Bundler Version:1.13.7
Rake Version:   12.0.0
Redis Version:  3.2.5
Git Version:    2.13.5
Sidekiq Version:5.0.4
Go Version: unknown

GitLab information
Version:    10.0.1
Revision:   2417795
Directory:  /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL:        https://git.site
HTTP Clone URL: https://git.site
SSH Clone URL:  git@git.git.site
Using LDAP: no
Using Omniauth: no

GitLab Shell
Version:    5.9.0
Repository storage paths:
- default:  /var/opt/gitlab/git-data/repositories
Hooks:      /opt/gitlab/embedded/service/gitlab-shell/hooks
Git:        /opt/gitlab/embedded/bin/git

我在Gitlab.com上的Issues

1 个答案:

答案 0 :(得分:0)

考虑到COPy策略将在tar / gz之前首先复制文件,这似乎是预期的。

如" Backup strategy option":

中所述
  

默认备份策略是使用Linux命令tar和gzip将数据从相应的数据位置流式传输到备份。
  这在大多数情况下都可以正常工作,但在数据快速变化时可能会出现问题。

     

当tar读取数据时数据发生变化时,错误文件会在我们读取时发生变化,并导致备份过程失败。
  为了解决这个问题,8.17引入了一种名为 copy 的新备份策略。该策略在调用tar和gzip之前将数据文件复制到临时位置,以避免错误。

     

副作用是备份过程占用额外的1X磁盘空间。该过程尽最大努力在每个阶段清理临时文件,因此问题不会复杂化,但对于大型安装而言,这可能是一个相当大的变化。这就是复制策略不是8.17中的默认策略的原因。

请参阅lib/backup/files.rb

    # Copy files from public/files to backup/files
    def dump
      FileUtils.mkdir_p(Gitlab.config.backup.path)
      FileUtils.rm_f(backup_tarball)

      if ENV['STRATEGY'] == 'copy'
        cmd = %W(cp -a #{app_files_dir} #{Gitlab.config.backup.path})
output, status = Gitlab::Popen.popen(cmd)

因此,创建的复制文件的时间戳将发生变化,使任何校验和都不同。