Daniel Pittman writes:
I had an issue with the machine that backuppc was running on recently,
in that one of the IDE cables was faulty and would *very* occasionally
corrupt a block or two.
I have resolved that hardware problem, and the resulting minor
corruptions to the ext3 filesystem that backuppc was resting on.
I am still using the Debian 2.0.2 package of BackupPC.
I have one question and a couple of suggestions coming out of that,
though:
My question is about the potential for corruption within the BackupPC
compressed pool. Presumable, at least one of the compressed pool files
will have a corrupt block somewhere within it.
I believe that BackupPC should detect this as a "changed" file next time
it does a full backup, and as a result should put a correct copy of any
corrupt file into the pool.
Is this understanding correct?
Yes. Full backups check and compare the file contents.
Incremental backups check just the attributes (just mtime for
smbclient and tar, everything for rsync), and then check the
contents only if the attributes have changed.
There is one exception: if you turn on rsync checksum caching
(available in 2.1.0), then just the cached block checksums are
used, instead of recomputing them from the file. So pool file
corruption will not be detected. However, there is a setting
$Conf{RsyncCsumCacheVerifyProb} (default is 1%) which means 1% of
the files will have their checksums re-verified when caching is
on. This means that the file contents will be validated on an
on-going basis.
The suggestions are to do with error detection and reporting. One of the
side-effects was that a handful of the pool directories got the wrong
ownership information, resulting in BackupPC failing to correctly create
links.
This was reported in the main LOG file, with the error:
BackupPC_link got error -4 when calling MakeFileLink(/var/lib/backuppc/pc/enki/152/f%2f/fusr/fshare/fdoc/fhyperspec/attrib, 68e66a6e4a361931c911266e230ff3f1, 1)
I didn't get any other notification that there were problems with the
backups for the machines, which I would have expected to see.
Would it be worth recording this sort of (fairly serious, really) error
somewhere more visible, or generating an email to the administrator?
Finally, since it is fairly clearly an error to have an odd ownership of
any of the pool directories, would it make sense to have the BackupPC
nightly process check for, and either correct or warn about, this sort
of thing?
More visible error reporting like this would be a nice idea.
Perhaps BackupPC_sendEmail should look through the main LOG
file and check for certain errors?
In place of that it makes sense to keep an eye on the log files
and backup errors.
Craig
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
