如果你除了代码，还需要备份用户账号、权限配置、Issue（工单）和 Merge Requests，就必须使用官方的备份工具。

1. 执行备份命令

在新 CentOS 服务器上，通过以下命令可以生成一个包含全站数据的 .tar 压缩包：

gitlab-rake gitlab:backup:create

备份文件默认会保存在 /var/opt/gitlab/backups/ 目录下。

2. ⚠️ 必须手动备份的两个“命根子”文件

很多人以为跑了上面的命令就万事大吉了，结果硬件损坏后发现依然无法恢复。因为 GitLab 官方的备份包不包含配置文件和加密密钥！

你必须通过脚本，把服务器上的以下两个文件异机备份（拷贝到别的服务器）：

/etc/gitlab/gitlab.rb （GitLab 的核心核心配置文件）

/etc/gitlab/gitlab-secrets.json （极其重要！ 包含数据库加密密钥。如果丢失此文件，即使拿到了备份包也无法解密数据，轻则用户密码全部失效，重则仓库直接报错打不开）。

3. 官方备份的自动异机同步机制

你可以修改 /etc/gitlab/gitlab.rb 文件，让 GitLab 备份完成后自动上传到其他远程服务器（如 AWS S3、阿里云 OSS、或者局域网内的另一台 FTP/SFTP 服务器）。

以简单的 SFTP 异机备份为例，可以在 gitlab.rb 中配置：

# 备份保留 7 天，过期自动删除，防止撑爆硬盘
gitlab_rails['backup_keep_time'] = 604800 
# 如果有条件，建议开启上传到外部对象存储（例如 MinIO 或 阿里云OSS）
# gitlab_rails['backup_upload_connection'] = { ... }

📝 总结：最高效的容灾策略

日常防线： 使用方案一的 Git 镜像脚本，每天在另一台机器上存一份纯代码的裸仓库。它的好处是极其轻量，恢复时完全不挑 GitLab 版本，硬件坏了能立刻顶上。

周常防线： 每周使用方案二跑一次官方备份，并将 gitlab-secrets.json 和 .tar 备份包一起拷走，用于灾难发生时的全站完美还原。

本文链接:http://it72.com/12809.htm