What happens with mirror corruption?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

What happens with mirror corruption?

Chris Wilson-3
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).

Does this count as an "increment" operation? (again, I assume so).

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).

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)

Sorry if you've already considered and accounted for this.

Happy new year to you all!

Cheers, Chris.
--
  ___ __     _
 / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |



_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: What happens with mirror corruption?

Ben Escoto
>>>>> Chris Wilson <[hidden email]>

>>>>> 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

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment