BackupPC-users

Re: [BackupPC-users] errors in cpool after e2fsck corrections

2009-01-18 10:22:13
Subject: Re: [BackupPC-users] errors in cpool after e2fsck corrections
From: Holger Parplies <wbppc AT parplies DOT de>
To: Matthias Meyer <matthias.meyer AT gmx DOT li>
Date: Sun, 18 Jan 2009 16:20:36 +0100
Hi,

Matthias Meyer wrote on 2009-01-18 15:33:30 +0100 [Re: [BackupPC-users] errors 
in cpool after e2fsck corrections]:
> Johan Ehnberg wrote:
> > Quoting Matthias Meyer <matthias.meyer AT gmx DOT li>:
> > 
> >> After a system crash and tons of errors in my ext3 filesystem I have to
> >> run e2fsck.
> >> During this I lost some GB of data in /var/lib/backuppc.
> >> [...]
> >> I believe the reason is that
> >> /var/lib/backuppc/cpool/8/4/5/845a684e4a8c9fe22d11484dc13e24fc
> >> is a directory and not a file. Probably during e2fsck created.

no, e2fsck does not *create* directories; this is a clear evidence of on-disk
data corruption.

> >> Should I delete all directories in /var/lib/backuppc/cpool/?/?/?/*
> >> or would BackupPC_nightly do this job?

I doubt so. BackupPC_nightly is not designed to fix broken file systems.

> > Sorry to hear about that. I would recommend the following:
> > - Consider all the backed up data corrupt (don't build any new backups on
> > it) - Start a fresh pool, saving the old one for the duration of your
> > normal cycle - Look for the reason for the crash/corruption and prevent it
> > from happening
> [...]
> I would believe the filesystem should be ok in the meantime. e2fsck needs to
> run 3 or 4 times and need in total more than 2 days. After this lost+found
> contains approximately 10% of my data :-( No chance to reconstruct all of
> them.
> 
> 1) So you would recommend:
> mv /var/lib/backuppc/cpool /var/lib/backuppc/cpool.sav
> mkdir /var/lib/backuppc/cpool

No. The point seems to be *getting rid of the corrupt file system*. You don't
know what exactly was corrupted on-disk. You have definite evidence that a lot
was - and possibly still is (3 or 4 e2fscks to find all problems? What should
a subsequent check find that a previous one didn't?). You can trust in
everything being ok now, but you might as well trust in not needing your
backups in the first place. You can't really verify it.

The key phrase is

> > - Look for the reason for the crash/corruption and prevent it
> > from happening

- this can likely mean exchanging the disk (cables, mainboard, memory, power
supply ...). You don't give any details about your system crash or hardware
setup, so there is little point in guessing what might have gone wrong.

Either your backup data and history are vitally important to you, in which
case you don't want to trust the current state of your pool file system for
future backups, or they aren't, in which case you can get rid of them and save
yourself future headaches. If you can avoid it, you probably don't want to
overwrite your current pool for a while, in case you need to restore
something. Making an archive of the last backup(s) seems unlikely to get every
file content right, so you could need to resort to versions of files in older
backups ...

> [...]
> During the deletion of old backups also old, (maybee corrupt) files in cpool
> will be deleted. So possible corrupt files in cpool will disappear
> automaticly during the next month.

Yes, but do you know the implementation of the ext[23] file system well enough
to tell what will happen to possible corruption of file system metadata?

Regards,
Holger

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
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/