Golang实现文件系统的快照备份与恢复

快照备份须用硬链接而非复制，需检查同设备、跳过非普通文件、原子替换恢复、记录校验和manifest、加文件锁防并发。

文件系统的快照备份，听起来高大上，但真正落地时，几个细节没抠到位，就可能变成“假备份”。用Go实现时，硬链接、原子替换、校验、并发锁——这四个坑，踩过的人不少。下面逐一拆解，顺便带点实操经验。

快照备份必须用硬链接而非复制

直接 cp -r 整个目录树？磁盘空间分分钟被撑爆，而且快照的核心语义——共享未修改文件——彻底丢了。Go 里正确的做法是：遍历源目录，对每个普通文件调用 os.Link() 创建硬链接到快照目录。注意，硬链接只能在同一文件系统内创建，跨分区会报 invalid cross-device link 错误，这个得提前判断。

实操建议：

• 先用 unix.Statfs()（依赖 golang.org/x/sys/unix）检查源路径与快照目标是否在同一设备（比较 Statfs.Fsid 是否相同）。
• 跳过目录、符号链接、设备文件等非普通文件。目录需要单独用 os.MkdirAll() 创建，不能硬链接。
• 对每个普通文件，先确保目标快照路径的父目录存在，再执行 os.Link(src, dst)。如果失败（跨设备场景），fallback 到 io.Copy 复制。

恢复时需避免覆盖正在使用的文件

从快照恢复可不是简单 cp -r 回原路径。如果原目录下有进程正在写入某个文件，直接覆盖可能会导致数据截断，甚至报 text file busy 错误。Go 里推荐用原子替换策略：先把快照中的文件复制到一个临时路径（比如 path.tmp），然后通过 os.Rename() 原子替换原文件。

实操建议：

• 遍历快照目录时，对每个文件计算它在原路径的对应位置（比如快照 /backups/20240501/etc/hosts → 原路径 /etc/hosts）。
• 写入前检查目标路径是否存在且可写。如果目标是符号链接，os.Stat() 会跟随，需要用 os.Lstat() 判断真实类型。
• 严禁直接 os.Remove() 原文件再 os.Create() —— 中间存在时间窗口，其他进程可能创建同名文件，导致意想不到的问题。

快照元数据必须记录时间戳与文件校验和

光靠目录名（比如 20240501）来做快照标识？不够。用户可能手动修改快照内容，或者备份中途崩溃，一致性没法保证。每次生成快照时，必须附带一份 manifest.json，里面记录每个文件的 ModTime、Size 和 SHA256（用 crypto/sha256 计算）。

实操建议：

• 生成快照前先 filepath.Walk() 扫描源目录，对每个文件打开并计算哈希。小文件可以全读入内存，大文件需要用 io.Copy 分块写入 hash.Hash。
• manifest 文件本身也要哈希，并在快照根目录写入 manifest.sha256 防止篡改。
• 恢复前先校验 manifest 完整性，再逐项比对目标文件哈希。如果不一致，说明原目录已被修改，应该中止恢复并告警。

并发快照操作需加文件锁防止冲突

多个 goroutine 同时对同一源目录发起快照？可能会导致硬链接指向错误文件，或者 manifest 写入混乱。Go 没有跨进程文件锁原语，必须依赖 syscall.Flock()（Linux/macOS）或 golang.org/x/sys/windows 的 LockFileEx（Windows）。

实操建议：

• 为每个源路径生成唯一锁文件路径（比如 /var/lock/snapshot_/etc.lock），避免全局锁造成性能瓶颈。
• 获取锁后立即检查快照目录是否已经存在同名时间戳目录（防止重复触发），再开始遍历。
• 锁必须在 manifest 写完且 fsync 成功后才释放，否则其他进程可能读到不完整的快照。

硬链接的限制、原子恢复的时机、manifest 的完整性校验、跨进程锁的粒度——这四点没处理好，快照就只是个看起来像备份的目录，不是真正可靠的恢复依据。