香港主机搭建私有代码仓库的访问与备份策略，重点不是“把代码复制一份”，而是同时管好谁能连接、哪些数据要保存，以及副本能否恢复。以自托管的 Gitea 为例，Git 仓库之外，配置、数据库、附件和密钥也可能影响服务完整性。下面按部署、访问、备份和恢复逐项说明。
先选访问方式：SSH 适合日常推送
个人或小团队可在香港主机部署 Gitea，使用 SSH 进行 Git 克隆、拉取和推送。SSH 密钥比反复输入账号密码更适合自动化开发流程；为每位成员单独配置公钥，人员离开时撤销对应密钥，不要共用一个管理员账号。
管理后台不要和代码访问入口混为一谈。可限制管理页面的来源地址，或通过 WireGuard 建立加密的内部访问通道；普通开发者仍按授权使用 SSH。若团队需要浏览器操作，可启用 HTTPS，并使用有效证书。无论哪种方式，都应及时安装安全更新、关闭不需要的端口，并为重要账号开启多因素验证（如服务支持）。
| 方式 | 适用情况 | 主要注意点 |
|---|---|---|
| SSH | 日常 Git 操作、自动化拉取 | 妥善管理私钥，按成员单独授权 |
| HTTPS | 浏览器访问，或网络限制 SSH 的环境 | 配置 TLS，避免明文传输凭据 |
| WireGuard | 限制管理入口，仅让授权设备接入 | 管理客户端密钥和设备撤销流程 |
备份不能只靠 Git 克隆
Git 本身便于分布式保存提交历史，但普通克隆通常不包含仓库平台的全部信息。Gitea 上的议题、合并请求、用户权限、附件和服务配置，可能另存于数据库或文件目录；启用了 Git LFS 时，大文件对象也需要单独确认是否纳入备份。只在开发电脑上留一份克隆，不能替代整套服务备份。
香港主机搭建私有代码仓库的访问与备份策略，应列出实际使用的数据清单：仓库目录、数据库、配置文件、附件、LFS 对象，以及恢复服务所需的密钥和版本信息。根据部署方式使用服务官方文档建议的备份方法；数据库和文件应保持一致，避免备份时数据库已更新、仓库文件却仍是旧状态。可安排维护窗口暂停写入，或采用受支持的一致性备份机制。
按步骤建立可恢复的副本
- 盘点数据：记录仓库位置、数据库类型、附件及 LFS 路径，并确认服务版本、配置和加密密钥的保存位置。
- 生成完整备份：使用对应版本文档中的备份流程，覆盖数据库与文件数据。不要只复制正在写入的数据库文件。
- 加密并转存：将备份加密后传到另一台主机、受控 NAS 或异地存储。备份账号采用单独凭据，限制其只能写入指定位置。
- 保留多个时间点：可从每日备份、保留数周开始，再根据代码变更频率、存储空间和恢复需求调整。关键项目可增加更频繁的副本。
- 做恢复演练：在隔离环境恢复一份备份，检查仓库历史、网页功能、附件和用户权限；验证无误后再更新恢复记录。
常见的“3-2-1 备份”原则，是保留多份副本、使用不同存储介质，并确保其中一份位于异地。它是规划思路，不代表任何备份天然可靠：异地副本若共享同一管理员账号，仍可能被误删或加密。尽量启用版本保留或不可随意改写的存储策略，并定期检查备份任务是否成功，而非只看任务是否启动。
恢复能力要靠测试确认
备份完成后，记录恢复所需的主机环境、服务版本、数据库方式和密钥位置。恢复测试优先在新建的隔离主机进行，避免覆盖生产数据。检查至少包括：能否登录、仓库能否克隆、历史提交是否完整、附件能否打开，以及成员权限是否符合预期。若仓库包含敏感代码，还要限制备份文件下载权限，并在人员或供应商权限变化时撤销旧凭据。
归根结底，香港主机搭建私有代码仓库的访问与备份策略，要把 SSH 或 HTTPS 的授权、平台数据清单、异地保存和恢复演练连成一套流程。先确保完整恢复，再按团队规模调整备份频率与保留时间。
常见问题
只备份 Git 仓库可以吗？
不一定。议题、权限、附件、配置和 LFS 对象可能不在普通仓库克隆中，应按实际部署逐项确认。
备份能否放在同一台香港主机？
可以作为临时副本，但主机故障或账号失陷可能同时影响原数据和备份。重要数据还应有独立的异地副本。
备份多久做一次？
根据代码变更频率和可接受的数据损失范围确定。每日备份可作为许多小团队的起点；高频变更项目可增加备份频率。
怎么判断备份有效？
定期在隔离环境恢复，并验证仓库、附件、权限及服务配置。单看备份文件存在，不能证明它可以正常恢复。