>>>>> Chris Wilson <[EMAIL PROTECTED]> >>>>> wrote the following on Tue, 03 Jan 2006 00:14:45 +0000 > Hi Ben and all, > > I was thinking about what might happen if the rdiff-backup destination > mirror copy became corrupted somehow (e.g. neutrino strike, bad disk > bits, bad RAM, etc) and I have a question. > > If the repository's mirror copy becomes slightly corrupted (one file's > data changes slightly for no good reason), and a subsequent backup > operation is run against it, the next backup should correct the > corruption to make the destination mirror file again match the source? > (I assume so).
Yes, assuming rdiff-backup thinks the file has changed. (The neutrino may not be kind enough to change the mtime, for instance.) In most cases rdiff-backup would not notice the change and the files would stay out of sync until the source file gets updated. > Does this count as an "increment" operation? (again, I assume so). Yes, if the file is marked as changed. > If so, then restoring the corrupted file to a point before the > corruption will re-introduce it, by undoing the corrective increment? > (previous incremental diffs, applied in reverse, will either fail to > apply if they touch the corrupted bit, or apply cleanly and leave the > corruption in place). I'm not sure, but I think diffs are only stored by offset, so I'm not sure a diff could fail to apply unless the size of the file changed. If the diff covers the corruption, I think this happy coincidence would produce an intact restored file. > Could rdiff-backup check for and avoid this? Presumably the strong > checksum stored in the metadata should match the file's checksum on the > source, not the target? Thus, if on a subsequent backup operation the > mirror file's checksum no longer matches the one in the most recent > metadata, this could only have happened by corruption of the mirror? > (or possibly, the source file changed during the backup). > > In this case, if the source file still matches the metadata checksum > (i.e. hasn't changed since the last backup), could rdiff-backup correct > the mirror _without_ writing an increment, so that subsequent restores > of that file past the corruption point will correctly restore the file > without corruption? > > If the source file has changed since the last backup, rdiff-backup would > not be able to repair the damage to the mirror, but could it at least > give a stern warning to the user in either case, that the mirror file > was corrupted? (and if the source has changed, that restoring past that > point will produce a corrupted file) What you say is possible, and an interesting plan, but not something rdiff-backup currently does. Right now, rdiff-backup doesn't check the hash of the mirror file unless you run it with --verify. You're right that this could be added, and it probably wouldn't be too much of resource drain, since the entire mirror file must be processed anywhere if we're constructing a signature of it. > Sorry if you've already considered and accounted for this. Nope, it's an idea I hadn't thought of :-) -- Ben Escoto
pgphK9D4bZq6b.pgp
Description: PGP signature
_______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
