during a full backup (whether using checksum-seed or not) if file attributes are unchanged but file content no longer matches, what happens? does backuppc merely treat it as a changed file, or does it treat this as an inconsistent situation worthy of admin attention? is something written to a log? which log and what is written (so i can grep)? and/or is it reported via email?
does checksum-seed merely make use of the same backuppc signature hash already used for pooling, or does it compute a different checksum? either way, it ought to usually or sometimes be possible to see whether bit rot occurred in the original or the backup (eg does the original or the backuppc_zcat still match the checksum). does backuppc look for this and report accordingly? also please let me know if i understand this correctly: during incremental backups, if file attributes have not changed it is presumed the file content also has not changed. during full backups, if checksum-seed remains commented, then for every file the entire content is compared via hash for every block, or if checksum-seed is enabled, then only ~RsyncCsumCacheVerifyProb of files will have their entire content checked (via hash for every block), while all other files will have their backuppc signature checksum computed and merely that will be compared. have i got that right? is there a good place other than the source to read about how this works in any particular release/version?
------------------------------------------------------------------------------
_______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
