Maarten Bezemer writes:
> On Tue, 15 Nov 2011, Dominic Raferd wrote:
>
>> On 15/11/2011 00:23, Alex Schuster wrote:
>
>>> Warning: Hash da39a3ee5e6b4b0d3255bfef95601890afd80709 of winXPPro-0.log
>>> doesn't match recorded hash db9943d0284382131b553cef380aae99871b0f2e!
>>>
>>> Any idea what has happened?
>
>> Vmware files for a running vm may change while being backed up by
>> rdiff-backup, in which case you don't have a consistent backup. Maybe this
>> is
>> why you have this inconsistent hash warning.
>
> If the contents changed during the rdiff-backup run, it bails out and
> doesn't save the (inconsistent) increment. So that shouldn't happen.
And I amusing a backup script which takes a LVM snapshot of my /home
partition before rdiff-backupping it. Sorry Dominic for not mentioning this.
Restoring other VMs seems to work, although I did not test many. But I
cannot restore ANY backup of this special VM I need, I tried about six
of my twenty backups.
Well, it would be really nice to be able to restore this VM, but if not,
I can (and have to) live with that. But I really would like to know why
this happened, and if I can trust other backups I do.
I successfully restored this VM in the past already, but that was an
earlier snapshot I have deleted meanwhile.
> My guess would be a RAM problem, which is more likely to cause corruption
> in huge vmware disk images than it is for smaller regular files.
Right. But the system is running stable otherwise. I am on Gentoo Linux,
where the whole system is compiled from source, and RAM errors tend to
show up as weird, unreproducible compilation errors there. Especialle
gcc is a good test for this, because it is compiled twice in the build
process, and the two results are compared bitwise. But I compiled gcc
for 24 times since I made that backup, without a problem.
> Another known cause for this type of corruption is a Via KT400a chipset
> when running with DDR400. Memtest won't find any errors, but repeatedly
> md5summing the same large file will result in wrong checksums every now
> and then ( < 5% of the cases, so try some 100 times... )
> But that kind of hardware should have been retired these days anyway.
I don't have this hardware, but thanks for the hint. Oh, and I also
don't have one of those Samsung SpinPoint drives that write an empty
block whenever the drive's identification is checked with hdparm.
Wonko
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
