一键安装Gitlab后的备份、迁移与恢复

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://linuxerxy.blog.51cto.com/10707334/1865414

1.Gitlab创建备份
#gitlab-rake gitlab:backup:create

使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1393513186_gitlab_backup.tar的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1393513186是备份创建的日期。
2.Gitlab恢复
# 停止相关数据连接服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq

# 从1393513186编号备份中恢复
gitlab-rake gitlab:backup:restore BACKUP=1393513186

# 启动Gitlab
sudo gitlab-ctl start

3.Gitlab迁移
迁移如同备份与恢复的步骤一样, 只需要将老服务器/var/opt/gitlab/backups目录下的备份文件拷贝到新服务器上的/var/opt/gitlab/backups即可(如果你没修改过默认备份目录的话)。但是需要注意的是新服务器上的Gitlab的版本必须与创建备份时的Gitlab版本号相同. 比如新服务器安装的是最新的8.5版本的Gitlab, 那么迁移之前, 最好将老服务器的Gitlab 升级为8.5再进行备份。
4.自动备份
通过crontab使用备份命令实现自动备份:

sudo su -
crontab -e

例如加入以下, 实现每天凌晨2点进行一次自动备份:

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

4.注意事项
添加这项是因为添加自动备份后的几天时间里,Gitlab所在的KVM一直宕机。通过模拟cron计划任务,发现第一条gitlab创建备份的过程是先备份出许多(db、repo等文件),再通过这些文件合并成一个备份压缩包,最后删除文件,只剩一个备份压缩包。这就相当于先产生2倍备份压缩包,导致磁盘爆满。

恢复过程中遇到一个错误:

Started GET "/EagleEye/BMH.EagleEye" for 127.0.0.1 at 2016-10-25 10:54:32 +0800
Processing by ProjectsController#show as HTML
Parameters: {"namespace_id"=>"EagleEye", "id"=>"BMH.EagleEye"}
Completed 500 Internal Server Error in 215ms (ActiveRecord: 19.5ms)

OpenSSL::Cipher::CipherError (bad decrypt):
app/models/project.rb:383:inimport_url’
app/models/project.rb:413:in external_import?'
app/models/project.rb:405:inimport?’
app/models/project.rb:421:in import_in_progress?'
app/controllers/projects_controller.rb:93:inshow’
lib/gitlab/middleware/go.rb:16:in call'

系统是centos 6.2的 ,gitlab是8.8.5迁移到另外一台服务器上的,其它页面都可以正常显示,但是一点击项目就会显示500,。查看/var/log/gitlab/gitlab-rails/production.log日志,发现上述错误 。
通过搜索知道,这是gitlab数据迁移时的一个缺陷。解决方法:

1、覆盖原来gitlab的 db_key_base 到新的gitlab
db_key_base 位置在 /etc/gitlab/gitlab-secrets.json

2、EE版本执行
sudo gitlab-rails runner "Project.where(mirror: false).where.not(import_url: nil).each { |p| p.import_data.destroy if p.import_data }"

CE版本执行
sudo gitlab-rails runner "Project.where.not(import_url: nil).each { |p| p.import_data.destroy if p.import_data }"

重启gitlab,发现500错误不见,项目能访问到。

本文出自 “echo xiayun” 博客,请务必保留此出处http://linuxerxy.blog.51cto.com/10707334/1865414

<think>好的,我现在要帮助用户解决在GitLab CI/CD自动化部署过程中如何备份文件的问题。用户希望了解最佳实践和配置方法。首先,我需要回忆之前用户提供的参考引用,特别是引用[1]和[2],看看有没有相关的内容可以借鉴。 引用[1]提到了一键迁移和优化CI/CD管道的重要性,以及使用测试自动化和并行测试作为最佳实践。这可能意味着在部署过程中,备份应该尽可能自动化,并且集成到现有的CI/CD流程中,减少手动干预。引用[2]是关于GitLab Runner的配置,提到了自动化部署的具体命令和运行方式,这可能需要结合GitLab Runner的配置来实现备份。 接下来,我需要考虑GitLab CI/CD中备份文件的常见方法。通常,备份可以在部署前或部署后进行,或者在特定阶段触发。用户可能需要将备份作为CI/CD流水线的一个阶段,例如在部署之前自动备份当前版本的文件,或者在成功部署后备份数据库等关键数据。 最佳实践可能包括使用GitLab的artifacts功能来保存备份文件,或者将备份上传到云存储服务如AWS S3、Google Cloud Storage等。同时,应该考虑如何触发备份,例如通过手动触发流水线,或者在每次部署时自动执行备份。另外,备份的版本控制和保留策略也很重要,避免占用过多存储空间。 配置方面,用户需要在.gitlab-ci.yml文件中定义备份的job,例如使用脚本执行备份命令,然后通过artifacts保存备份文件,或者使用scp、rsync等工具将文件传输到远程服务器。同时,可能需要集成环境变量来管理敏感信息,如存储服务的访问密钥。 还需要注意安全性,确保备份文件加密,特别是在传输和存储过程中。另外,错误处理也是关键,比如备份失败时如何通知相关人员,或者回滚到之前的备份版本。 可能的问题是如何将备份步骤无缝集成到现有的部署流程中,而不会影响部署的速度和稳定性。这时候可以考虑并行执行备份和部署,或者将备份放在部署后的阶段,确保部署成功后再进行备份。 最后,根据用户的引用[1]中的建议,优化CI/CD管道应该减少摩擦,因此备份过程需要高效且可靠,可能需要使用现有的工具或服务来简化配置,比如使用GitLab的集成功能或第三方插件。 总结一下,回答应该包括以下几个部分:备份阶段的选择(部署前/后)、备份文件的存储位置(artifacts或云存储)、脚本配置示例、安全性措施、版本控制,以及可能的回滚策略。同时,结合用户提供的引用,强调一键迁移和自动化的重要性,确保备份过程无缝集成到CI/CD流程中。</think>在GitLab CI/CD中实现自动化部署时的文件备份,需结合流水线阶段设计和存储策略,以下是最佳实践及配置方法: --- ### **1. 备份阶段设计** - **部署前备份**:在部署新版本前,备份当前运行版本的关键文件或数据库,确保回滚能力。 ```yaml backup_before_deploy: stage: pre-deploy script: - tar -czvf app_backup_$(date +%F).tar.gz /var/www/app - mysqldump -u $DB_USER -p$DB_PASS $DB_NAME > db_backup_$(date +%F).sql artifacts: paths: - *.tar.gz - *.sql expire_in: 1 week # 设置备份文件保留时间[^1] ``` - **部署后备份**:在部署成功后,备份新版本配置文件或初始化数据。 ```yaml backup_after_deploy: stage: post-deploy script: - cp /etc/app/config.yml config_backup_$(date +%F).yml only: - main # 仅针对主分支触发 ``` --- ### **2. 存储策略** - **使用GitLab Artifacts** 通过`artifacts`关键字临时存储备份文件,适用于短期保留: ```yaml artifacts: paths: - backups/ expire_in: 3 days ``` - **上传至云存储** 集成AWS S3、阿里云OSS等对象存储服务,实现长期归档: ```yaml backup_to_s3: script: - apt-get install -y awscli - aws s3 cp app_backup.tar.gz s3://my-bucket/backups/ variables: AWS_ACCESS_KEY_ID: $S3_ACCESS_KEY # 在GitLab CI/CD变量中配置 AWS_SECRET_ACCESS_KEY: $S3_SECRET_KEY ``` --- ### **3. 安全性版本控制** - **加密敏感备份** 使用`openssl`或`gpg`加密备份文件: ```yaml scripts: - tar -czvf - /var/www/app | openssl enc -aes-256-cbc -out app_backup_encrypted.tar.gz.enc -pass pass:$ENCRYPT_KEY ``` - **版本标签关联** 将备份文件Git标签绑定,便于追踪: ```yaml backup_with_tag: script: - tar -czvf app_${CI_COMMIT_TAG}.tar.gz /var/www/app ``` --- ### **4. 回滚机制集成** 在`.gitlab-ci.yml`中定义回滚任务(需手动触发): ```yaml rollback: stage: rollback variables: BACKUP_FILE: "app_backup_2023-08-01.tar.gz" script: - aws s3 cp s3://my-bucket/backups/$BACKUP_FILE . - tar -xzvf $BACKUP_FILE -C /var/www/app when: manual # 仅手动执行 ``` --- ### **5. 优化实践** - **并行备份测试**:利用`parallel`关键字加速流水线[^1]。 - **清理旧备份**:通过`expire_in`或存储服务生命周期策略自动删除过期文件。 - **通知机制**:备份失败时发送Slack/邮件告警: ```yaml backup_notify: script: - curl -X POST -H 'Content-type: application/json' --data "{\"text\":\"Backup failed: $CI_PIPELINE_URL\"}" $SLACK_WEBHOOK when: on_failure ``` --- ### **配置示例** 完整`.gitlab-ci.yml`片段: ```yaml stages: - pre-deploy - deploy - post-deploy backup_before_deploy: stage: pre-deploy script: - ./scripts/backup.sh # 封装备份逻辑 artifacts: paths: - backups/ expire_in: 1 week deploy_prod: stage: deploy script: - ansible-playbook deploy.yml environment: name: production backup_config: stage: post-deploy script: - cp /etc/nginx/nginx.conf nginx_backup_$(date +%F).conf - aws s3 cp nginx_backup_*.conf s3://config-backup/ ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值