Re: [Bug-ddrescue] broken partition table and solaris

[Ariel]

On Tue, 9 Jan 2007, David Erixon wrote:

> I´m running opensolaris and a while ago I accidentally "erased" 200gb of
> data due to a faulty management software. What happened was that the
> software erased the current partition table and created a new one. I have
> tried various approaches to get my data back and/or to restore the original
> partition table through the backup labels that I´ve heard should be stored
> for each disk. The restoring of the partition table has not worked for
> various reasons and I´ve come to the conclusion that it would probably be
> easier to just copy the data to another disk. I know that the data is still
> there because when I tried out a bunch of restore software for linux and
> windows I actually found one that could read and show me my data (Stellar
> Phoenix). This software is unfortunately way out of my budget and

Have you tried gpart and TestDisk? See also here: 
http://www.linux.com/howtos/Partition/recovering.shtml

> none of the others I´ve found can read solaris partitions except ddrescue.

ddrescue does not read partitions. The operating system does. And linux 
has support for solaris partitions, if you compile it that way.

ddrescue will read bad sectors from a disk and keep going. It has nothing 
to do with partitions.

Perhaps you are looking for a tool to copy data from an entire disk, 
ignoring partitions? Then maybe you want dd.

You don't need ddrescue unless your hard disk is physically damaged.

> The problem though, is that in my case, ddrescue seems to read only the
> empty inodes from the new partition table (which of course consists of the
> whole disk). Is there a way around this? Is this when I should start
> thinking of reading the raw device instead (which I´ve also tried btw)?

Hu? I think you are confusing terms. A partition table contains 
partitions. A partition will contain a filesystem, and a filesystem will 
contain inodes.

What did it not read? There is no such a thing as an 'empty' inode, unless 
you mean a file of size 0.

> the commands I´ve tried so far looks like this, where c0d1 is the faulty
> disk, 200gb in size, and c2d0 is a new disk, 400gb in size, which I´ve
> partitioned as a single large partition and created a filesystem on (which
> became slice 0). c0d1s2 refers to the backup partition on the old disk which
> I though at least theoretically could include my missing data (I´m uncertain
> of this one)
>
> ddrescue -B -n /dev/dsk/c0d1s2 /dev/dsk/c2d0s0 rescued.log
>
> I´ve also tried reading the raw device, something like:
> ddrescue -B -n /dev/rdsk/c0d1s2 /dev/dsk/c2d0s0 rescued.log
>
> both commands reads a lot of data to the new disk. when I fsck the new disk
> I get a lot of errors about either wrong superblocks or incomplete inodes
> etc. The raw read seems to be worse than the block read and usually includes
> large number of negative sizes for the inodes. If I let fsck solve the
> problems it found and I mount the partition, I end up with something that
> seems to be a empty. This make me think that I´ve been trying to
> a) read 200gb of empty data
> b) read something but then "wiped" the corrupt/incomplete data to zero again
> c) read the wrong thing, the wrong way.
> d) that there is some sort of incompability of the block sizes of the old
> and the new disk
>
> any ideas, thoughts, suggestions is greatly appreciated. It´s very possible
> that I´ve missed something important, please let me know if so.

The problems you are having with fsck stem from not reading from the 
"start" of the filesystem. Maybe the backup partition table has old data 
that does not match where the data really is?

fsck starts checking the filesystem; it notes that it doesn't look like a 
filesystem, so it complains about the superblock. It then fixes it. Then 
it goes looking for inodes - but guess what: none of the inodes are in the 
right place. So it erases them (since they are corrupted), eventually you 
end up with a totally empty disk since fsck "fixed" all the errors it 
found.

But in truth the problem is that you did not copy from the start of the 
filesystem, you copied before it, or after it.

You need to find a tool that will search the disk, tell you the _REAL_ 
start of the filesystem, then use dd to copy the data starting there to 
the new disk.

        -Ariel

PS. It seems you are very confused with terms regarding filesystems, 
partitions, slices, etc. Please try to find some docs on these subjects, 
it will help you with the recovery - or at the very least help you phrase 
the questions.

PPS. Please try gpart, it was made to do exactly what you need, and 
supports solaris partitions.