Linux GitLab如何备份与恢复

Linux GitLab 备份与恢复实操指南

一 备份

• 使用内置命令创建备份（Omnibus 包推荐）
  • 手动备份：执行 sudo gitlab-backup create（等效于 sudo gitlab-rake gitlab:backup:create），备份默认生成在 /var/opt/gitlab/backups/，文件名形如 1750765308_2025_06_24_16.7.6_gitlab_backup.tar。建议同时备份配置文件：sudo tar -cf gitlab_conf.tar /etc/gitlab。
• 修改备份目录与保留策略
  • 编辑 /etc/gitlab/gitlab.rb：
    • gitlab_rails['manage_backup_path'] = true
    • gitlab_rails['backup_path'] = "/data/gitlab-backups"
    • gitlab_rails['backup_archive_permissions'] = 0644
    • gitlab_rails['backup_keep_time'] = 604800（保留 7 天，单位为秒）
  • 使配置生效：sudo gitlab-ctl reconfigure。
• 定时备份（Cron）
  • 示例（每天 02:00）：0 2 * * * /opt/gitlab/bin/gitlab-backup create（如用 rake，可用 /opt/gitlab/bin/gitlab-rake gitlab:backup:create）。
• 远程/异地备份
  • 结合 scp 或 rsync 将备份文件自动拷贝到备份服务器，建议基于 SSH 免密登录实现无人值守。
• 备份内容范围
  • 内置备份包含仓库、数据库、用户与权限等；注意：/etc/gitlab 配置与 SSH 主机密钥默认不包含，需单独备份。

二 恢复

• 版本要求与准备
  • 恢复目标机的 GitLab 版本应与备份时一致或更新（推荐一致）。查看版本：sudo gitlab-rake gitlab:env:info | grep "GitLab version"。
• 停止写入服务
  • 执行：sudo gitlab-ctl stop puma 与 sudo gitlab-ctl stop sidekiq（如为旧版本，可能是 unicorn 而非 puma）。
• 放置备份文件
  • 将备份 tar 放入配置的备份目录（默认 /var/opt/gitlab/backups/），文件名需与备份时一致（含时间戳前缀）。
• 执行恢复
  • 执行：sudo gitlab-backup restore BACKUP=1750765308_2025_06_24_16.7.6（仅填时间戳前缀，不要带 _gitlab_backup.tar 后缀）。过程中会提示确认，输入 yes 继续。
• 启动与验证
  • 启动：sudo gitlab-ctl start；检查状态：sudo gitlab-ctl status。Web 登录验证项目、用户、权限是否恢复；必要时执行 sudo gitlab-rake gitlab:check SANITIZE=true 做一致性检查。
• 迁移场景
  • 在新服务器恢复时，先安装同版本 GitLab，恢复前先 gitlab-ctl reconfigure；恢复完成后再 reconfigure 一次以确保组件注册正确。

三 常见问题与处理

• 版本不一致
  • 恢复失败或异常多与版本不匹配有关，务必保证目标机版本等于或高于备份机版本。
• 扩展权限错误（PostgreSQL）
  • 报错如：ERROR: must be owner of extension pg_trgm 或 btree_gist。处理：
    • 进入 sudo gitlab-psql，执行 DROP EXTENSION IF EXISTS pg_trgm; DROP EXTENSION IF EXISTS btree_gist; \q，再重新恢复；或在支持的版本中 ALTER EXTENSION ... OWNER TO gitlab; 。恢复后可按需重建扩展：CREATE EXTENSION pg_trgm; CREATE EXTENSION btree_gist; 。
• 服务未完全停止导致恢复失败
  • 恢复前确保 Puma/Sidekiq（或旧版的 Unicorn/Sidekiq）已停止，必要时 sudo gitlab-ctl stop 全停后再恢复。
• 502/权限异常
  • 恢复后若访问异常，检查目录权限与 socket 访问，必要时重启：sudo gitlab-ctl restart。
• 备份保留与清理
  • 通过 gitlab_rails['backup_keep_time'] 控制保留天数，避免磁盘被占满。

四 实用脚本与自动化

• 本地定时备份脚本（示例）
  • 路径与日志可按需修改：

    #!/usr/bin/env bash
    BACKUP_DIR="/var/opt/gitlab/backups"
    LOG="$BACKUP_DIR/backup_$(date +%F).log"
    
    echo "[$(date)] 开始备份" >
        >
         "$LOG"
    /opt/gitlab/bin/gitlab-backup create CRON=1 >
        >
         "$LOG" 2>
        &
        1
    if [ $? -eq 0 ];
         then
      echo "[$(date)] 备份成功" >
        >
         "$LOG"
    else
      echo "[$(date)] 备份失败" >
        >
         "$LOG"
    fi
    # 清理7天前
    find "$BACKUP_DIR" -name "*.tar" -mtime +7 -delete
    

  • Cron 示例（每天 02:00）：0 2 * * * /usr/bin/bash /path/to/backup.sh。
• 远程备份脚本（基于 SSH 免密）
  • 将最新备份自动 scp 到备份机，并在备份机按天数清理旧文件，适合灾备。

五 关键注意事项

• 备份命令选择
  • Omnibus 推荐使用 gitlab-backup create；gitlab-rake gitlab:backup:create 仍可用。
• 配置文件与密钥
  • 备份命令不会包含 /etc/gitlab 与 SSH 主机密钥，务必单独打包并妥善保管，迁移时一并恢复。
• 备份路径与权限
  • 自定义路径需在 gitlab.rb 设置 gitlab_rails['backup_path'] 并 gitlab-ctl reconfigure；确保运行 GitLab 的用户对目录有读写权限。
• 恢复会覆盖数据
  • 恢复前请确认目标实例可被覆盖或处于测试环境；恢复过程中会提示清空现有数据，输入 yes 继续。
• 定期演练
  • 定期在测试环境演练恢复流程，验证备份可用性与完整性，确保真实灾难时可快速恢复。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！