From: Holger P. <wb...@pa...> - 2009-01-18 15:20:55
|
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 <mat...@gm...>: > > > >> 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 |