BackupPC-users

[BackupPC-users] patch to make more robust against corrupted filesystem

2009-07-08 11:56:34
Subject: [BackupPC-users] patch to make more robust against corrupted filesystem
From: Tim Connors <tconnors AT astro.swin.edu DOT au>
To: backuppc-users AT lists.sourceforge DOT net
Date: Thu, 9 Jul 2009 01:36:36 +1000 (EST)
I know there have been threads on here debating the relative merit of
throwing out all of the data on a backup disk that suffered major
filesystem damage, vs trying to fix it and let backuppc regenerate any
files that might have corrupted data (via setting a
RsyncCsumCacheVerifyProb of 1 and redoing all machines as full backups).

In light of just how much data I would be throwing out including several
machines that have been archived and then decomissioned, I opted to try to
restore the filesystem and let backuppc keep writing to it.  And it seems
to have worked and is still working for me several months later, so I'm
confident all is well in the world.

The only trouble I had was several attrib files were corrupted, so
unpack() barfed with a die() (can't remember what it died of, and my
logs have long since been rotated away, but I suspect it was that
unpack() dies on invalid memory references rather than segfaulting,
which is awfully kind of it) and didn't let me back up anything (usually
dying about 95% of the way through a 32 hour backup, dagnamit).  Below was
my solution to make it more robust.  Once every machine had done a full
backup, the eval would no longer fail because there was always a valid
attrib file.

This or something like it is probably worth including in upstream, because
cosmic rays can always happen, so it's good to not let unpack() kill the
entire backup when the pool has some slightly corruped data.

--- Attrib.pm.debian-3.1.0-6    2009-07-09 01:15:43.000000000 +1000
+++ Attrib.pm.attrib_fix        2009-07-09 01:14:59.000000000 +1000
@@ -252,11 +252,18 @@
            $fd->read(\$newData, 65536);
            $data .= $newData;
        }
-       (
-            @{$a->{files}{$fileName}}{@FldsUnixW},
-            @{$a->{files}{$fileName}}{@FldsUnixN},
-            $data
-        ) = unpack("w$nFldsW N$nFldsN a*", $data);
+        eval {
+           (
+            @{$a->{files}{$fileName}}{@FldsUnixW},
+            @{$a->{files}{$fileName}}{@FldsUnixN},
+            $data
+           ) = unpack("w$nFldsW N$nFldsN a*", $data);
+       };
+       if ($@) {
+           $a->{_errStr} = "unpack: Can't read attributes for $fileName from 
$file $@";
+            $fd->close;
+           return;
+       }
         if ( $a->{files}{$fileName}{$FldsUnixN[-1]} eq "" ) {
             $a->{_errStr} = "Can't read attributes for $fileName"
                           . " from $file";


-- 
TimC
"Any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Lisp."                   -- Greenspun's Tenth Rule of Programming

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
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/

<Prev in Thread] Current Thread [Next in Thread>
  • [BackupPC-users] patch to make more robust against corrupted filesystem, Tim Connors <=