硬链接不是备份手段，而是同一文件系统内共享数据的机制；它通过指向相同inode实现多路径访问，适用于增量快照备份，但不可跨分区、不能用于目录，且需用files.issamefile()验证是否同源。
硬链接本身不是“实现备份”的手段，而是文件系统层面的共享数据机制。它不能替代备份逻辑，但能作为高效备份策略中的关键优化环节——前提是理解它的限制与适用场景。
硬链接的本质：同一份数据的多个入口
硬链接指向的是同一个 inode（Linux/macOS）或文件 ID（Windows NTFS），所有硬链接都等同于原始文件：修改任一链接内容，其他链接同步可见；删除其中任意一个，只要还有其他硬链接存在，数据就不会丢失。这决定了它天然适合“多版本快照式备份”——比如每天生成一个硬链接指向当前数据库文件，实际只存一份数据，却拥有多个时间点的可访问路径。
- 必须在**同一文件系统内**创建（不能跨分区、不能跨挂载点）
- 目标文件**必须已存在**，且不能是目录（绝大多数系统禁止对目录建硬链接）
- 所有硬链接拥有完全相同的权限、时间戳、大小等元数据
- 无法通过 Path 或 File 对象直接识别“哪个是原始链接”，它们地位完全平等
用 Files.createLink() 创建硬链接备份
Java NIO 提供了标准、跨平台的方式创建硬链接：
Path src = Paths.get("/data/latest.db");
Path backup = Paths.get("/backup/db-20260728.db");
try {
Files.createLink(backup, src); // 创建硬链接
} catch (FileAlreadyExistsException e) {
// 可选择先删除再重建，或跳过
Files.deleteIfExists(backup);
Files.createLink(backup, src);
} catch (IOException e) {
throw new RuntimeException("无法创建硬链接备份", e);
}
注意：该操作不复制数据，毫秒级完成；失败时通常因跨文件系统、目标已存在且不可覆盖，或权限不足。
如何验证是否真正共享同一份数据
仅靠路径名或文件名无法判断两个文件是否为硬链接。正确方式是使用 Files.isSameFile()：
boolean isSame = Files.isSameFile(
Paths.get("/data/latest.db"),
Paths.get("/backup/db-20260728.db")
); // 返回 true 表示它们指向同一物理文件
这个方法内部会解析符号链接、获取底层唯一标识（inode 或文件 ID），并跨平台一致工作，比手动读取属性更可靠安全。
配合备份流程的实用建议
- 增量快照模式：每次备份前，用 Files.deleteIfExists() 清理旧链接，再 createLink() 指向最新文件。目录中保留的多个硬链接，就是多个时间点的“轻量级副本”
- 避免误删风险：硬链接无主次之分，删除原始路径和删除备份路径效果相同。生产环境建议配合只读挂载或 ACL 控制写权限
- 监控真实占用：用 du -sh /path/to/dir 查看目录实际磁盘用量，而非 ls -l 统计链接数——后者会高估空间
- 不适用于网络文件系统：NFS、Samba 等通常不支持硬链接，或行为不一致，慎用于远程备份目标
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
