Re: [rdiff-backup-users] What happens with mirror corruption?

[Ben Escoto]

>>>>> Chris Wilson <address@hidden>
>>>>> 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

pgpwqLgiAWfHk.pgp
Description: PGP signature