[nSLUG] Data Recovery...

Dop Ganger nslug at fop.ns.ca
Fri Jan 30 16:53:43 AST 2009


On Thu, 29 Jan 2009, Daniel Morrison wrote:

> 2009/1/29 Stephen Gregory <nslug at kernelpanic.ca>:
>> Daniel Morrison wrote:
>>>
>>> dd conv=noerror bs=4096 if=/dev/sda of=/dev/sdb

I find sdd (ftp://ftp.berlios.de/pub/sdd) a preferable alternative as it 
copes better with failing drives.

>> But I don't recommend using dd. If the drive is bad dd will likely
>> stress the drive and make it worst.
>
> Can you explain?  I always figure that dd will read each bit on the
> disk exactly once, whereas mounting it, even read-only, will cause
> repeated accesses to key portions (e.g. root directory inode,
> superblock, etc.).

dd will retry multiple times to read the data. sdd -noerror -noseek will 
only try the once, which (a) significantly speeds things up, and (b) means 
if it's a mechanical problem it puts less stress on the failing part so 
it's more likely the copy will complete.

>> You can use the sb= option with mount to specify an alternate
>> superblock. See the mount manpage under the ext2 specific options. This
>> may allow you to recover some data. If only some of the drive is damaged.
>
> That's a good idea, but... mounting an unclean filesystem is a bad
> idea (although read-only is less dangerous).  If someone has imaged a
> copy as I suggested, then fsck on the alternate superblock will repair
> the original, making it possible to mount without this option.

I have used mke2fs -S in the past to rescue a drive with multiple trashed 
superblocks. As the man page notes, this is very much a last ditch option, 
but it does actually work and turned a drive full of random noise back 
into my Courier source code with only a few errors.

>> I would mount the filesystem readonly with the -r argument for mount.
>
> And then?  How to find and copy data without stressing the disk or
> (worst case) crashing your system?

Crossed fingers? ;-)

I always operate on images I've taken. Anything that can't be read on the 
original drive is usually not readable without sending it off to a DR lab 
anyway, so when I do it I try to pull off as much data as possible and 
leave the original drive to one side.

Cheers... Dop.



More information about the nSLUG mailing list