[svlug] Drive recovery

J C Lawrence claw at kanga.nu
Wed Jul 19 22:09:01 PDT 2000


On Wed, 19 Jul 2000 20:48:12 -0700 
Karen Shaeffer <shaeffer at best.com> wrote:

> On Wed, Jul 19, 2000 at 02:24:59PM -0700, J C Lawrence wrote:
>> On Wed, 19 Jul 2000 16:01:59 -0500 Ed Okerson
>> <eokerson at quicknet.net> wrote:
>> 
>> It really ia "just" a matter of taking a sector editor to the
>> disk and carefully searching the disk for the appropriate
>> signature patterns, extracting the data from them, and the
>> calculating from there where the partition must have started and
>> then where it must have ended, verifying that by checking the
>> data there, computing the matching CHS etc values and writing
>> them to the partition table (with appropriate educated guessing
>> for exactly hwo they handled primary vs logical partitions), and
>> so forth.  No magic, just a lot of mind numbing work.

> OK, if gpart (see Seth's post) won't do it, then you try the brute
> force thing.

Yup.

> Your method is the brute brute force one. 

Yup.

When I'm messing with critical data I don't (and didn't) have a
whole lot of trust in fancy tools that didn't pre-state *EXACTLY*
what they were doing.

> Correct me if I'm wrong: I believe most filesystems back up
> partition tables. 

Not that I'm aware of.  Certainly not back when I did my
recoveries.  

You need to realise that the partition table and filesystems exist
at two very different levels.  The partition table caves up a disk
and defines regions of disk which may be treated as a single unit
and doesn't care one whit what the contents of that block are, just
where they are on the disk.  A filesystem takes such a unit and puts
a storage pattern on it suitable for directories and files etc and
doiesn't give a damn where on the disk it is, just what the data
content is.  Partition tables don't know about filesystems and
filesystems don't know about partition tables.  Each one lives in an
area outside the other's purview.

> So, there is likely to be a copy of your last good partition table
> somewhere on the disk. 

True.  Several partitioning tools now backup the partition table in
any of various places.  Hope in this area is going to depend on what
you partitioned the disk with in the first place.  I just don't know
about the standard Linux partitioning tooks (disk druid, cfdisk
etc).

> I think each filesystem has it's own partition table signature
> that will be written in the last bytes of the sector which stores
> the partition table. 

No.  The partition table will have a flag byte that contains the
partition type (which is really an arbitrary number) but that's
about it.  Most filesystems then reserve a few sectors for
themselves at the beginning or end of the partition for various
data, wherein those sectors also contain fixed signature strings
which can be searched for.  In fact, many common file system
structures often have signature strings which can be searched for,
which can make manually rebuilding a toasted filesystem somehwat
easier.

Note: I don't know about Ext2FS.  I've never had to dig into it at
this level of detail.  Back when I was hacking filesystems it was
all HPFS, FFS, and VsFS.

That all said, the data above only true for x86 systems wherein the
partition table structure is extremely dumb and limiting.  Other
platforms have more intelligent/capable partitioning schemes which
allow for more intelligent recovery and manipulation (eg Solaris and
IRIX come to mind).

> So, if you can identify what the particular signature of your
> partition table is, then you can search the end of each sector
> looking for that byte sequence. If you find it, then you could
> copy that sector into the boot sector--and you may recover your
> disk...

Yup.  Beware false matches (the plagued me).

-- 
J C Lawrence                                 Home: claw at kanga.nu
---------(*)                               Other: coder at kanga.nu
http://www.kanga.nu/~claw/        Keys etc: finger claw at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--




More information about the svlug mailing list