Hi, sorry for replying so late, busy week.
Matthias Meyer wrote on 2009-07-20 21:59:49 +0200 [Re: [BackupPC-users] Restore issues]: > Vetch wrote: > > I tried restoring a backup to my system - it kept on failing with aborted > > by signal=PIPE. > > I have a feeling it may have been related to corrupt files within the > > hardlinks, since when I tried restoring using tar, the tar files were not > > readable, How did you create the tar file(s), what was the error reported? Was it completely unreadable, or did it abort on a specific file? Always the same file? Did you try with different source backups? Even though you might be interested in the lastest versions of your files, choosing an older backup to restore might give you some clues (or older versions of missing files). > > and the zip files didn't have as many files in as I would have > > expected... How did you create the zip file(s)? > > I guess if there are problems with the data, there's probably nothing that > > can be done? > > Probably not much :-( Well, the part of the data that is unaffected should be, err, unaffected. There is probably a lot you can do, assuming a partial restore is better than nothing. You might be able to restore older versions of files that are missing in the latest backup. One of the virtues of BackupPC is that you have file level access to all files. It's not like a read error on a tape or a compressed archive, beyond which all data may be lost. And you can quickly locate different versions of the same file in different backups. If the problem is with the tar stream (e.g. a huge file that is incorrectly encoded), you can always directly access the files with BackupPC_zcat, though that won't scale to "many files". But it does mean you may be able to access more data than at first apparent. > > How does backuppc check the consistency of the data once it's been added > > to the pool? > > I know that it only backs up the data once, but how does it make sure that > > the data is in a valid state? That is not completely true. Depending on the XferMethod, each *full* backup will either re-transfer the complete data set and reuse only perfectly matching pool files (i.e. on-disk corruption would *not* cause a corrupted file to be reused), or at least check all data against the stored backup and re-create any changed files (also causing corrupted files not to be reused). With rsync(d) and --checksum-seed in RsyncArgs this checking is limited to RsyncCsumCacheVerifyProb - 1% of the files by default - so a corrupted file may in fact be reused. This is why this behaviour is turned *off* by default (i.e. if you didn't enable it, it's off; if you did, you know it, and it's your fault ;-). > I didn't believe that backuppc will check data consistency. That is the job > of a filesystem. e2fsck will do that for ext2/3 file systems. That is incorrect. e2fsck will check *file system metadata* for *detectable* corruption. I don't believe e2fsck will attempt to read all used data blocks - that could take hours on large file systems, and would make the badblocks(8) program somewhat pointless - and, in any case, it couldn't check data consistency beyond detecting read errors reported by the disk hardware. So, no, e2fsck will do nothing more than confirm that your file system metadata has no detectable errors. > You should run it regulary. Yes, probably. Though I have not yet heard any reports of if and in what time e2fsck successfully completes for BackupPC pool file systems. It may or may not have problems with the large number of files with more than one link. I don't know. > I assume you are running BackupPC on Linux and use ext3 as filesystem. > So I would advise: > 1) make a image backup (e.g. partimage) of your /var/lib/backuppc or > wherever your __TOPDIR__ resides. This part is the most important of all. e2fsck can effectively lose data you could have accessed before (or, at least, make it next to impossible to find). If your file system is already damaged beyond recognition, you don't have much options, but it doesn't seem to be. I'd recommend mounting it read-only instead of checking it. As soon as you have a copy of as much data as you can (and need to) retrieve, you can run e2fsck and see if the situation improves. For your BackupPC pool, I wouldn't recommend trusting a repaired file system (unless only trivial things were repaired that didn't make much of a difference in the first place). File system metadata doesn't contain much redundancy to allow for reconstructing lost information. Unattached inodes can be found, but will you have any idea, where in which backup(s) lost+found/#123456 really belongs? Incorrect link counts can be "corrected", but that does not restore the missing links, it simply acknowledges the fact that they have been lost. Contradictory information, that would crash the file system driver, can be resolved, so that it will not, but that does not mean the result is "correct" in the sense of "as it was before corruption". If your BackupPC pool file system needs more than trivial correction, you've got a problem, and you should face it. > You should run e2fsck as soon as possible. Elsewere filesystem errors can > grows and destroy more data then necessary. Yes, allocating a block marked as free but in fact used for a directory would do quite some damage, obviously. That is why I would mount the FS read-only. If you e2fsck it, e2fsck -p it. > I have had a similiar problem 7 month ago. How do you know? There was no file system corruption reported in this thread, was there? Regards, Holger ------------------------------------------------------------------------------ _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
