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 AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
