On Jan 8, 2013 11:20 PM, "Florian Philipp" <[email protected]> wrote: >
-- snip -- > > Hmm, good idea, albeit similar to the `md5sum -c`. Either tool leaves > you with the problem of distinguishing between legitimate changes (i.e. > a user wrote to the file) and decay. > > When you have completely static content, md5sum, rsync and friends are > sufficient. But if you have content that changes from time to time, the > number of false-positives would be too high. In this case, I think you > could easily distinguish by comparing both file content and time stamps. > > Now, that of course introduces the problem that decay could occur in the > same time frame as a legitimate change, thus masking the decay. To > reduce this risk, you have to reduce the checking interval. > > Regards, > Florian Philipp > IMO, we're all barking up the wrong tree here... Before a file's content can change without user involvement, bit rot must first get through the checksum (CRC?) of the hard disk itself. There will be no 'gradual degradation of data', just 'catastrophic data loss'. I would rather focus my efforts on ensuring that my backups are always restorable, at least until the most recent time of archival. Rgds, --
