技术帮助 · 发布时间：
私有 Git 服务看似只保存代码，实际还可能包含 Git LFS 对象、附件、钩子配置和服务数据库。租用计算设备搭建私有Git服务的磁盘与快照策略，应在投入使用前明确五件事：数据放在哪里、空间是否够用、快照是否一致、保留多久，以及怎样验证恢复。
一、确认仓库数据落在正确的磁盘上
先区分系统盘与数据盘。系统盘用于操作系统和服务程序，仓库、LFS 对象及相关数据库则应放在规划好的数据卷上。若服务目录仍位于系统盘，系统升级、重装或系统盘容量不足都可能影响仓库。
检查数据盘是否已格式化、挂载点是否固定，并确认服务进程对目录有读写权限。对于使用 ext4 或 XFS 的设备，可将磁盘按文件系统标识配置为开机自动挂载；不要只依赖可能变化的设备名。重启后还要确认服务目录确实指向数据盘，而不是意外写进系统盘上的同名空目录。
二、按增长来源核算容量与告警线
仓库容量不等于工作树当前文件的大小。Git 会保留历史对象；Git LFS 则可能单独保存大文件对象。还要计入数据库、日志、临时文件以及快照所需空间。删除分支也不一定立即释放对象空间，清理前应先确认仓库策略和恢复需求。
上线前记录现有数据占用，并为预计增长留出余量。可先把磁盘使用率达到约70%设为提醒线、约85%设为需要处理的高风险线；这只是常见运维起点，应根据写入速度、扩容耗时和服务商的磁盘计费方式调整。除容量外也要监控 inode 使用率：小文件很多时，即使尚有剩余容量，也可能因 inode 耗尽而无法创建文件。
三、确定快照覆盖范围与一致性
云平台或虚拟化平台提供的磁盘快照，通常用于保存某一时点的磁盘状态，但不同平台对正在写入的数据如何处理并不相同。单纯对运行中的磁盘拍快照，可能得到崩溃一致状态；若数据跨多个磁盘，分别拍摄的时间差也可能造成内容不匹配。
先列出服务数据清单，确认仓库目录、LFS 存储和数据库分别在哪个卷上。数据库应采用其支持的备份或一致性机制；仅拍摄数据卷快照，不一定能保证数据库与仓库处于同一时点。对规模较小、允许短暂停写的服务，可安排维护窗口，暂时禁止推送，完成数据库一致性处理后再创建快照；不能停写时，则应按平台和数据库文档配置应用一致性流程。
四、写清频率、保留期和独立备份
快照频率要对应可接受的数据丢失范围，也就是恢复点目标（RPO）。若最多只能接受一天内的数据变化丢失，可考虑每日备份；代码更新频繁、恢复点要求更短时，应提高频率，或使用能够提供相应一致性保证的备份方案。频率越高，存储费用和管理负担通常也越大。
同时明确保留数量、自动过期规则和责任人。例如可按日保留短周期备份、按周保留较长周期副本，具体天数应结合变更频率、合规要求和预算决定。不要把同一数据盘上的快照视为完整灾备：设备故障、账户权限丢失或误删操作可能同时影响原盘和快照。重要仓库应另有不同存储位置的备份，并限制删除权限。
五、上线前做一次恢复演练
快照显示“成功”不等于服务一定能恢复。应准备独立测试环境，从备份中恢复仓库及必要的数据库，再检查仓库是否能读取、分支和标签是否存在、LFS 对象能否取回，以及用户能否完成克隆或推送。可使用 Git 自带的 git fsck 检查仓库对象的完整性；它不能替代应用层验证，但能发现部分对象损坏问题。
- 记录数据卷、挂载点、服务目录和数据库位置，确认快照覆盖范围。
- 在维护窗口或一致性机制就绪后创建首份快照，并记录创建时间与保留规则。
- 将备份恢复到隔离环境，核对仓库、LFS 对象、权限和服务配置。
- 记录恢复所需时间，并据此判断是否满足业务恢复时间目标（RTO）。
- 定期复测；磁盘迁移、服务升级或备份策略变更后，也要重新验证。
常见问题
快照能代替异地备份吗？
不能完全代替。快照适合快速回退，但若与原盘共享故障域或权限，灾难发生时可能一并失效。
Git 仓库和数据库必须放在同一块盘吗？
不一定。分盘便于分别扩容和管理，但备份时要考虑两者的时间一致性，避免恢复后仓库与数据库记录对不上。
磁盘快满时，先删旧快照还是扩容？
先确认快照保留规则及删除影响；若空间紧张且不能安全清理，优先评估扩容。不要在未验证备份的情况下删除唯一可用恢复点。
归纳起来，租用计算设备搭建私有Git服务的磁盘与快照策略，要把数据位置、容量告警、一致性、保留与隔离、恢复演练连成闭环。上线前逐项核对，并在变更后复测，才能让快照真正成为可用的恢复手段。
