Presumably in an ideal world with no tradeoffs, every backup would be full and filled as that would make sure each backup is standalone independent without any need to merge or fill anything later on.
*Full vs incremental* If I understand it correctly, the difference between incrementals and fulls is that for incrementals, if the attribs match, the files are assumed to match, avoiding the need for full file checksums. So it makes sense to mix in incrementals between full backups in order to speed up incremental backups relative to what a full would take. *Filled vs. Unfilled* If I understand it correctly, unfilled backups don't include unchanged files in the backup file tree. For v3, this made sense as it eliminated the need to add yet more hard linked files that take time to create and consume inodes. It's not as clear to me in v4 what the advantage is given that all the file information is stored in the attrib file itself which needs to be read anyway. It wouldn't seem that inefficent to me to just write out the full directory attrib for all backups regardless of whether changed or not. - The inode wastage is a lot less in that you are only storing one file per directory and you would need an attrib file anyway if any file were to change in the directory. - There is no "messy" creation of hard links In all, I would even think that filled would still in general be faster than unfilled in that you don't need to merge up the incremental tree to see if there are changes -- all presumably much slower than just writing the attrib file to each directory. Said another way, in v4, why not just make all backups filled while still mixing incrementals between filled to overall speed up average backup time. _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
