![如果文件名被重命名,口是心非会重新发送所有数据](https://linux22.com/image/183464/%E5%A6%82%E6%9E%9C%E6%96%87%E4%BB%B6%E5%90%8D%E8%A2%AB%E9%87%8D%E5%91%BD%E5%90%8D%EF%BC%8C%E5%8F%A3%E6%98%AF%E5%BF%83%E9%9D%9E%E4%BC%9A%E9%87%8D%E6%96%B0%E5%8F%91%E9%80%81%E6%89%80%E6%9C%89%E6%95%B0%E6%8D%AE.png)
让我们创建一个test/
包含随机 1 GB 文件的目录:head -c 1G </dev/urandom >test/1GBfile
,然后使用表里不一:
duplicity test/ file:///home/www/backup/
然后/home/www/backup/
包含一个加密的存档,占用约 1 GB。
然后我们添加一个几个字节的新文件:echo "hello" >test/hello.txt
,并重做备份:
duplicity test/ file:///home/www/backup/
仍然backup/
是 ~ 1 GB。像增量备份中一样,只创建了一些小于 1 KB 的文件。
现在让我们重命名 1 GB 文件:mv test/1GBfile test/1GBfile_newname
并重做增量备份:
duplicity test/ file:///home/www/backup/
然后backup/
现在是〜2 GB!。
为什么duplicity
不考虑文件内容相同但名称不同的事实?
在这里,如果我们使用网络,即使文件内容完全相同,我们也会浪费 1 GB 传输。duplicity
通常rsync
可以解决这个问题,有没有办法避免这个问题?
添加.txt文件后登录:
--------------[ Backup Statistics ]--------------
StartTime 1605543432.43 (Mon Nov 16 17:17:12 2020)
EndTime 1605543432.72 (Mon Nov 16 17:17:12 2020)
ElapsedTime 0.29 (0.29 seconds)
SourceFiles 3
SourceFileSize 1073745926 (1.00 GB)
NewFiles 2
NewFileSize 4102 (4.01 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 2
RawDeltaSize 6 (6 bytes)
TotalDestinationSizeChange 230 (230 bytes)
Errors 0
-------------------------------------------------
重命名文件后登录:
--------------[ Backup Statistics ]--------------
StartTime 1605543625.97 (Mon Nov 16 17:20:25 2020)
EndTime 1605543840.72 (Mon Nov 16 17:24:00 2020)
ElapsedTime 214.76 (3 minutes 34.76 seconds)
SourceFiles 3
SourceFileSize 1073745926 (1.00 GB)
NewFiles 2
NewFileSize 1073745920 (1.00 GB)
DeletedFiles 1
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 3
RawDeltaSize 1073741824 (1.00 GB)
TotalDestinationSizeChange 1080871987 (1.01 GB)
Errors 0
-------------------------------------------------
TotalDestinationSizeChange 1080871987 (1.01 GB)
,啊啊!该文件刚刚被重命名!
答案1
似乎duplicity
确实不“处理重命名”,请参阅此处的此专栏:https://wiki.archlinux.org/index.php/Synchronization_and_backup_programs#Chunk-based_increments
由于duplicity
使用librsync
(即不“处理重命名”),看起来很正常。