增量备份需基于内容哈希校验变化，不能仅依赖文件名、大小或修改时间；应先用st_size和st_mtime快速筛选，再对疑似变更的小文件计算哈希，以兼顾准确与性能。
增量备份不是简单复制文件，而是只备份自上次备份以来变化的部分；校验不是只比对文件名或大小，而是必须基于内容哈希。直接用 shutil.copy 或 os.listdir 做“伪增量”会漏掉修改但大小未变的文件，也扛不住硬链接、权限变更等场景。
用 os.stat() 和 hashlib 判断文件是否真正变化
仅靠修改时间（st_mtime）不可靠：NFS挂载、时钟不同步、编辑器重写文件时可能重置时间戳。必须结合内容哈希——但全量读取大文件太慢，所以先快速排除明显未变的文件：
- 先比对
st_size和st_mtime，两者都相同才进入哈希校验 - 对小文件（比如
）直接全量 <code>hashlib.md5()；对大文件用分块读取（chunk_size=8192），避免内存暴涨 - 注意：Windows 上
st_mtime精度只有 1 秒，同一秒内多次修改会被视为“未变”，必须依赖哈希
用 sqlite3 存储文件指纹，而非 JSON 或 CSV
每次备份都要查“这个文件上次备份时的哈希是多少”，频繁读写文本格式会成为瓶颈，且并发写入易出错：
- 建表语句：
CREATE TABLE IF NOT EXISTS files (path TEXT PRIMARY KEY, size INTEGER, mtime REAL, hash TEXT, backup_time REAL) - 查询用
SELECT hash FROM files WHERE path = ?，带WHERE条件的主键查询是 O(log n) 级别 - 更新用
INSERT OR REPLACE INTO files VALUES (?, ?, ?, ?, ?)，避免先查后插的竞态 - 不要把绝对路径存成裸字符串——用
os.path.normpath()统一斜杠方向，否则C:\data\file.txt和C:/data/file.txt会被当成两个文件
处理符号链接、硬链接和权限丢失问题
默认的 shutil.copy2() 会复制权限和时间戳，但不处理符号链接本身；硬链接在备份目录里会变成独立副本，浪费空间：
立即学习“Python免费学习笔记（深入）”；
- 遍历源目录时用
os.walk(follow_symlinks=False)，单独记录os.path.islink()的路径，并用os.readlink()保存目标路径 - 对硬链接，通过
os.stat().st_ino和os.stat().st_dev判断是否重复——同一设备上的相同 inode 只需备份一次，后续用os.link()复制硬链接 - Linux/macOS 上用
shutil.copy2()；Windows 不支持完整权限，改用shutil.copy()+ 手动调用win32security（需 pywin32）
增量备份脚本必须带锁机制和中断恢复能力
没有锁的脚本在定时任务中并发运行，会导致数据库损坏或备份目录状态不一致；意外中断（如 Ctrl+C、断电）后不能从头再来：
- 用
sqlite3.connect(..., timeout=30)配合PRAGMA journal_mode=WAL提升并发安全性 - 在备份开始前写一个临时标记文件（如
.backup_in_progress），结束时删除；启动时检查该文件，若存在则读取上次已处理的路径继续执行 - 每次成功备份一个文件后，立即更新数据库并
conn.commit()—— 不要攒到最后再提交，否则中断就丢全部进度 - 不要用
time.time()当备份时间戳，改用datetime.now().astimezone().isoformat()，避免夏令时跳变导致时间倒退
真正的增量备份难点不在算法，而在细节一致性：inode 处理、时区、锁粒度、中断点位置——这些地方出错，备份集就不可信。校验阶段必须独立于备份逻辑，用另一份脚本遍历目标目录，重新计算哈希并与数据库比对，而不是相信“我刚写进去的一定是对的”。
