![即使只有 atime 或 mtime 不同,GNU tar 增量备份是否会再次保存整个文件?](https://linux22.com/image/176727/%E5%8D%B3%E4%BD%BF%E5%8F%AA%E6%9C%89%20atime%20%E6%88%96%20mtime%20%E4%B8%8D%E5%90%8C%EF%BC%8CGNU%20tar%20%E5%A2%9E%E9%87%8F%E5%A4%87%E4%BB%BD%E6%98%AF%E5%90%A6%E4%BC%9A%E5%86%8D%E6%AC%A1%E4%BF%9D%E5%AD%98%E6%95%B4%E4%B8%AA%E6%96%87%E4%BB%B6%EF%BC%9F.png)
mkdir test
echo "hi" > test/file1
tar -c -f archive.0.tar -g test.snar test
touch -a test/file1 # changes atime and ctime, doesn't change mtime
tar -c -f archive.1.tar -g test.snar test
tar -t -G -vv -f archive.1.tar # lists Y for file1
那么,即使只更改了访问时间 (atime) 和元数据更改时间 (ctime),GNU tar 是否会再次存储整个文件?对我来说,这似乎效率极低,因为我们可以合理地预期许多文件会被读取但不会被更改。
答案1
用于gtar
增量备份是不可靠的,但这并不是错误处理时间戳的结果。
任何在用户态工作的备份工具都无法像例如那样检查内部文件系统结构,zfs send
需要以相同的方式处理时间戳,否则无法授予正确的增量备份。
atime
与备份无关,因为它仅提示文件已被读取,而不提示文件是否已被修改。mtime
从第一眼看来可能很有趣,但也无关紧要。这是因为mtime
文件的 可以被用户空间程序设置为任何值。ctime
是增量备份唯一重要的时间戳,因为这是唯一无法操纵的时间戳。
由于内容和元数据都ctime
无法被操纵并且ctime
会更新,因此备份工具需要在文件内容和文件元数据每次ctime
更新时对其进行归档。
因此,明显未更改的文件mtime
仍可能具有已修改的内容,因此需要在备份中
最后:GNU tar 没有实现您要求的方法。该行为是硬编码的。
star
然而,它提供了 2004 年创建的选项-dumpmeta
,以便尝试增量备份。star
但是明确警告使用此选项,请参阅手册页:
-dumpmeta 更改增量转储模式下 star 的行为。如果使用 -dumpmeta 并且自上次增量转储以来仅更新了文件的 inode 更改时间 (st_ctime),则 star 将仅归档文件的元数据(例如 uid、权限等),而不归档文件内容。使用 -dumpmeta 将导致较小的增量转储,但在两个增量之间创建并在 st_mtime 中设置为旧日期的文件(例如,作为 tar 提取的结果)将不会以完整内容进行存档。因此,使用 -dumpmeta 可能会导致增量转储不完整,请务必小心使用。
star
默认使用的方法是从 1981 年左右ufsdump
开始使用的ufsrestore
,这是从 2005 年 2 月开始使用的方法star
,使用这些程序恢复增量备份从来没有出现过问题。