dump/restore corrupted filesystems

Jerry McAllister jerrymc at msu.edu
Mon Apr 16 22:32:03 UTC 2007

On Mon, Apr 16, 2007 at 11:14:35PM -0500, CyberLeo Kitsana wrote:

> Roland Smith wrote:
> > On Mon, Apr 16, 2007 at 09:11:48AM -0500, CyberLeo Kitsana wrote:
> >> I have a 1.2TB UFS2 filesystem with irrecoverable corruption. As such, I
> >> must move all 500GB or so of data off of it and re-newfs it.
> > 
> > If the corruption is due to hardware failure, your data is probably lost.
> Sorry if I wasn't clear. Most all of the data is readable and complete
> if I mount the filesystem read-only. It just panics the box when mounted
> read/write, and fsck can't fix the damage.
> My question was more along the lines of whether or not dump/restore
> would see that those corrupted directory and file inodes were indeed
> corrupt and not bother attempting to back them up, or if it would
> happily back them up and restore them in their corrupted state to a new
> filesystem, thus trashing it.

It depends on how they are corrupted.  Really there are three situations.

In the first, something happened to cause a problem with the filesystem
structure - the block and their pointer chains/links.   That would make
fsck see errors and possibly refuse to complete.  If that also affects
the ability to read some actual file then neither dump/restore nor any
other copy method will fix the situation.  dump and other utilities will
fail when reading the files and abort.    

You might be able to tinker around a little, figure out which actual files 
are affected and delete them or set dump not to read them and then copy 
all the rest.   But, if you are unable to mount the filesystem as write, 
this might not work.   If you are able to copy most, then those files 
would be uncorrupted in the new location.   You would just have to 
figure out what to do about the files you could not read.

Second would be a similar corruption to the filesystem structure 
blocks and links, but it happens to luckily not be in a place
currently being used by any actual files.   In this case, fsck
would fail, but you could still read the files enough to copy
them to some other space.   In this case, the copy process, whether
dump/restore or some other - dump/restore is probably best - would
fix the problem nicely.   The copy would be uncorrupted.

The third situation would be where the data itself was miswritten - 
maybe by a routine that cobbled some computation or database utility 
or whatever.  In this case, fsck would not see any problem with the 
filesystem.  It would see that all the blocks and links were nicely 
accounted for.  But the data would be bad and no amount of copying
would fix it.  If fact, dump or any other copy utility would read
the files without errors just fine and dandy, because it would not
know of the corruptions - so they would just follow it to the new copy.

dump/restore won't make any difference to/fix any fsck type errors.   
It works above that level - on the files' data itself.   fsck works
below the file level, on blocks and file chain links, etc.  If fsck
finds an unfixable error, dump or any other utility will fail too
if the error is in the area it is trying to read.

When you have dump-ed, then if you need to restore in to a cleanly created
new filesystem.  Remember that newfs created a filesystem on a partition.
Then the copy should not be corrupted from an fsck point of view.  This is 
not because of anything that dump/restore would do, but because the newfs 
made a clean new system that fsck would be happy with.

Now, if the data itself is corrupt - but readable, then dump will
happily read the corrupt data and restore will happily write out
what dump created.   The data would be just as incorrect.   But,
again, that is not at the fsck level.   It is at the file and
directory level.   fsck works on blocks and links and doesn't care
anything about the actual data written in the blocks.   It can
find errors in blocks and links that are both in a real file chain or
not currently part of any real file.   Generally fsck can fix those, 
but there are some things that it cannot make a reasonable guess on.

I hope this adds to the understanding rather than just confusing
you more.   Basically I am pointing out that there can be different
types or places for corruption.   No copying of files will fix a
problem if the errors are within the structure or data of the file
itself.   But, since fsck doesn't look at the actual data, but 
rather on structural integrity in the filesystem - the entity within
which the files reside, it is possible that it can find errors in
places that are not part of an actual current file.   If the latter
is the case, then copying the files out of the corrupt filesystem
in to a nice new one, freshly newfs-ed using dump/restore or some 
other method, can fix the problem.

But, if there are errors in the data, then no method of copying the
files will fix them.   And, if the filesystem corruption makes it
impossible to read some of the files, then no copying scheme will
fix them.   You might be able to tinker around, find which files
are unreadable, delete them, and then do the dump and get everything
else.   That could possibly made reconstruction a little easier.

> If it does, I can always use rsync.

I don't know how rsync will do it, but I am guessing that the result
will be somewhat similar to dump/restore.   If the files can be read
successfully, it will read them and write them in the new place.   If
actual data is corrupted, it will probably be transfered along with its
corruptions.   If the filesystem corruptions are not in an actual file,
then it should produce about the same results as dump/restore.

> > Dump examines the filesystem to see which files need to be backed up.
> > So dumping a corrupted FS will probably not produce the desired
> > results. If it did, we wouldn't need backups.

dump looks at the last modified date in the file header.  If it 
was changed (or created) after the last dump of the level you choose,
then it will add the file to its list of files to dump.  It does not
actually attempt to read file data until after making this index of
files to dump based on last dump data and dump level.

> Ironically, this is the machine that holds the backups.

Well, it can happen.
All thing that can not easily be recreated should be backed up.


> --
> Fuzzy love,
> -CyberLeo
> Technical Administrator
> CyberLeo.Net Webhosting
> http://www.CyberLeo.Net
> <CyberLeo at CyberLeo.Net>
> Furry Peace! - http://www.fur.com/peace/
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

More information about the freebsd-questions mailing list