Gitea 备份加密：从 dump 打包到 GPG 恢复验证的完整落地路径

Gitea 备份加密从 dump 打包到 GPG 恢复验证的完整落地路径【免费下载链接】giteaGit with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD项目地址: https://gitcode.com/GitHub_Trending/gi/gitea上次机房迁移同事把前一天gitea dump生成的压缩包顺手丢进了共享网盘。事后拆开一看里面是所有仓库源码、完整数据库还有带着 SMTP 密码的app.ini。从那以后Gitea 备份加密才被正式写进我们的运维流程——备份包默认是明文丢到哪等于泄到哪。威胁场景分级不加密到底会漏掉什么先说结论风险不在会不会被攻击而在备份文件经过的每一个环节都可能被看到。按威胁等级拆开看威胁等级典型场景现实可能性会漏掉的内容L1 本地越权同机其他服务账号、容器逃逸进程读取备份高全部数据库与仓库L2 内部误共享备份被拖进网盘、聊天群、工单附件高代码 配置 凭据L3 传输链路拦截明文scp、跨网段拷贝被截获中传输中的完整备份包L4 服务器物理接触硬盘被拆走、维修窗口期低磁盘上所有备份文件L1 和 L2 才是日常里真正高频的坑。L4 概率低但一旦发生就是全量泄露所以下面的路线都会把它算进去。家底清点dump 命令打包了什么、权限给到哪结论先行gitea dump能打全量包但它是压缩包不是加密包。打开 cmd/dump.godump 命令的默认行为和可选项很直白cli.StringFlag{ Name: type, Usage: Dump output format, default to zip, supported types: strings.Join(dump.SupportedOutputTypes, , ), },--type支持zip、tar、tar.zst等 9 种格式这些定义在 modules/dump/ 的 dumper 里。注意列表里全是压缩算法没有一个加密选项zst、gzip 只省空间不解密根本打不开。默认打包范围覆盖数据库 SQL 导出、全部仓库文件、LFS 对象、app.ini、custom 目录、data 目录附件、包、日志每一项都可以用--skip-*参数单独剔除。落盘时权限是这样的if err os.Chmod(outFileName, 0o600); err ! nil { log.Info(Cant change file access permissions mask to 0600: %v, err) }0600意味着仅文件属主可读写这能挡住 L1 场景里的同机其他用户但对 L2~L4 完全无效。所以原生能力的边界很清楚权限管得住本机管不住离开本机之后的任何一步。三条防护路线零依赖兜底、GPG 对称、公钥体系按防护强度递进选哪条取决于你的备份包要经过几个环节。路线 A权限 目录隔离 传输加密零依赖兜底适合小团队、备份只在一台备份机上过夜的场景。核心动作是把 L1 和 L2 两个高频场景堵死# 备份落盘到独立目录 ./gitea dump --file /var/lib/gitea/backups/gitea-$(date %F).zip chmod 700 /var/lib/gitea/backups # 加密传输到远端不做明文 scp rsync -e ssh /var/lib/gitea/backups/ backup-host:/secure/gitea/ # 恢复解压后导入 gitea-db.sql回拷 data 目录重启服务传输环节换成ssh/rsync之后L3 也被顺带覆盖。缺点落盘到传输之间备份在本地仍是明文窗口期内被摸到就全没了。路线 BGPG 对称加密流水线适合单人管理、备份要长期存着的场景。一条管道从备份到密文落盘./gitea dump -f - --type tar | \ gpg --batch --yes --symmetric --cipher-algo AES256 \ --passphrase-file /etc/gitea/backup.pass | \ gpg -o /var/lib/gitea/backups/gitea-$(date %F).tar.gpg chmod 600 /var/lib/gitea/backups/gitea-*.tar.gpg # 解密恢复 gpg --batch --decrypt --passphrase-file /etc/gitea/backup.pass \ /var/lib/gitea/backups/gitea-20260829.tar.gpg | \ tar -x -C /tmp/restore-20260829/etc/gitea/backup.pass本身就是敏感文件权限同样要锁到 600。⚠️ 密码短语文件必须和备份分开存放——放同一台机器同一目录时等于没加密。有条件就放硬件密码管理器或另一台机器备份时临时取用。路线 COpenSSL 公钥体系面向跨部门协作和自动化场景加密脚本跑在定时任务里只有持有私钥的管理节点能解。# 一次性初始化 openssl genrsa -out /etc/gitea/backup.key 3072 openssl rsa -pubout -in /etc/gitea/backup.key -out /etc/gitea/backup.pub # 备份并加密落盘 ./gitea dump -f - --type tar | \ openssl smime -encrypt -aes256 -inkey /etc/gitea/backup.key \ -out /var/lib/gitea/backups/gitea-$(date %F).tar.enc \ /etc/gitea/backup.pub # 解密恢复 openssl smime -decrypt -inform DER -inkey /etc/gitea/backup.key \ -in /var/lib/gitea/backups/gitea-20260829.tar.enc | tar -x -C /tmp/restore私钥 600、只留管理节点一份公钥可以分发给任何执行备份脚本的主机——这就是它适合自动化的原因。端到端演练备份、存储到恢复验证的完整闭环三条路线的骨架其实是同一条链恢复验证是整套流程里最容易被跳过、出事时最要命的一步。三个检查点落到命令上tar -tf /tmp/restore/gitea.tar /dev/null # 检查点1结构完整 mysql gitea -e SELECT COUNT(*) FROM repository; # 检查点2与备份前记录比对 cd /tmp/restore/repo/myrepo.git \ git rev-list --count HEAD # 检查点3与备份前一致顺带一提gitea restore-repo见 cmd/restore_repo.go只负责把单个仓库的数据单元装回实例全量恢复仍要靠解压 导入数据库 回拷目录这条手工链别指望一条命令包办。备份操作本身建议记入日志在 custom/conf/app.example.ini 的[log]段里配好FILE_NAME配合 modules/log/ 的轮转策略事后追责有据可查。高频误区对照备份加密最常翻车的三个地方误区正确做法权限设成 644觉得组内可读就行文件 600、目录 700备份用户专用密码短语和备份放在同一目录密钥离线存放至少跨目录跨机器只备份、从不演练恢复每季度一次完整解密 还原演练把 zst/tar.gz 压缩当成加密压缩不解密打不开必须显式 GPG/OpenSSL✅ 一句话记住这套体系传输加密 × 存储加密 × 权限最小化三项缺一备份就只是暂时还没泄露的明文。拿它对照现在的现状问自己三个问题最新的备份文件ls -l输出是什么、目录权限是 700 吗昨天的备份包你能在十分钟内解密并通过三个检查点吗密码短语此刻放在哪里——和备份同一个目录吗三个问题都答得上来这套闭环才算真正立住了。【免费下载链接】giteaGit with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD项目地址: https://gitcode.com/GitHub_Trending/gi/gitea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考