Is there a good way to copy a disk with an overwritten disk label
block-by-block into a file for analysis? The original data should all
still be there.

The disk had 3 slices (swap, / and /export). Unfortunately I don't
know the exact layout of the partitions, so I can't just re-create the
label on the disk. It was UFS formatted on a SPARC system. And it's an
FC-AL drive, so no easy way to plug it into a PC to copy out the data.

I haven't tried this yet (for lack of a place of storing the disk
image to), but I would imagine that trying to do
  dd if=/dev/dsk/c0t0d0s2 of=disk.img ...
is not going to go over so well, given that there's no disk label and
hence no slices.

I guess what I am looking for is an equivalent to Linux's /dev/sda
device that accesses the whole disk.

Do you guys happen to know of any tricks that might work getting the
data back?

Thanks,
-Markus

On Thu, 10 Sep 2009 20:27:47 -0700 (PDT), Markus <mman75@gmail.com>
wrote:

>Do you guys happen to know of any tricks that might work getting the
>data back?

You should be able to create a disklabel with a partition spanning the
whole disk.

To find your partition you should scan the disk looking for the magic
numbers of both filesystems. The first superblock is always block 32.
Then recreate a corresponding layout and try fsck if it finds a valid
filesystem.

Good Luck!
Emil

Markus <mman75@gmail.com> wrote:
> Is there a good way to copy a disk with an overwritten disk label
> block-by-block into a file for analysis? The original data should all
> still be there.

use the dd command.


> 
> The disk had 3 slices (swap, / and /export). Unfortunately I don't
> know the exact layout of the partitions, so I can't just re-create the
> label on the disk. It was UFS formatted on a SPARC system. And it's an
> FC-AL drive, so no easy way to plug it into a PC to copy out the data.
> 
> I haven't tried this yet (for lack of a place of storing the disk
> image to), but I would imagine that trying to do
>  dd if=/dev/dsk/c0t0d0s2 of=disk.img ...
> is not going to go over so well, given that there's no disk label and
> hence no slices.
> 
> I guess what I am looking for is an equivalent to Linux's /dev/sda
> device that accesses the whole disk.

/dev/rdsk/diskblahlblahs2 (note the s2. s2 = entire disk)

> Do you guys happen to know of any tricks that might work getting the
> data back?

fsck might figure it out, but work from your copied data first. If you 
know your disk is botched up, back it up.

Cydrome Leader wrote:
> Markus <mman75@gmail.com> wrote:
>> Is there a good way to copy a disk with an overwritten disk label
>> block-by-block into a file for analysis? The original data should all
>> still be there.
> 
> use the dd command.
> 
> 
>> The disk had 3 slices (swap, / and /export). Unfortunately I don't
>> know the exact layout of the partitions, so I can't just re-create the
>> label on the disk. It was UFS formatted on a SPARC system. And it's an
>> FC-AL drive, so no easy way to plug it into a PC to copy out the data.
>>
>> I haven't tried this yet (for lack of a place of storing the disk
>> image to), but I would imagine that trying to do
>>  dd if=/dev/dsk/c0t0d0s2 of=disk.img ...
>> is not going to go over so well, given that there's no disk label and
>> hence no slices.
>>
>> I guess what I am looking for is an equivalent to Linux's /dev/sda
>> device that accesses the whole disk.
> 
> /dev/rdsk/diskblahlblahs2 (note the s2. s2 = entire disk)
> 
>> Do you guys happen to know of any tricks that might work getting the
>> data back?
> 
> fsck might figure it out, but work from your copied data first. If you 
> know your disk is botched up, back it up.
> 
> 

Excellent advice.  When a file system is damaged or corrupted somehow, 
always make a block for block byte for byte copy as the first thing you 
do.  If your efforts at recovery make matters worse, you still have a 
copy.  Make another copy and work on that one.  Keep the corrupted copy 
until you are certain that you have recovered everything possible.

Remember that backups are much cheaper than the data recovery people.
Usually backups are much faster than the data recovery people as well!

On Sep 11, 3:06=A0pm, Cydrome Leader <prese...@MUNGEpanix.com> wrote:
> Markus <mma...@gmail.com> wrote:
>
> use the dd command.

Which is exactly what I am suggesting in my original message.

> > I haven't tried this yet (for lack of a place of storing the disk
> > image to), but I would imagine that trying to do
> > =A0dd if=3D/dev/dsk/c0t0d0s2 of=3Ddisk.img ...
> > is not going to go over so well, given that there's no disk label and
> > hence no slices.
>
> > I guess what I am looking for is an equivalent to Linux's /dev/sda
> > device that accesses the whole disk.
>
> /dev/rdsk/diskblahlblahs2 (note the s2. s2 =3D entire disk)

But only if there's a disk label that says so. s2 spans the entire
disk only by convention. If there's no label, the system won't know
how big s2 is. And there's no label on my disk...

That's different from Linux where /dev/sda is its own device and will
thus always address the entire disk, whether it's partitioned or not.

> fsck might figure it out, but work from your copied data first.

That is the idea and that's why I asked how to make such a byte-for-
byte copy.

I'll try labelling the disk with just s2 spanning the whole drive.
That should be sufficient to be able to make a disk image from the
drive. I would have just preferred to avoid writing to the drive
altogether and work from the disk image. That doesn't seem to be
possible, though. Looks like I'll have to re-label it in order to make
the copy.

Thanks for the tips.

Regards,
-Markus

In article <45d6b5fc-536f-4138-8e19-5d42ed1ac2d5@k13g2000prh.googlegroups.com>,
	Markus <mman75@gmail.com> writes:
> On Sep 11, 3:06�pm, Cydrome Leader <prese...@MUNGEpanix.com> wrote:
>> Markus <mma...@gmail.com> wrote:
>>
>> use the dd command.
> Which is exactly what I am suggesting in my original message.
>> > I haven't tried this yet (for lack of a place of storing the disk
>> > image to), but I would imagine that trying to do
>> > �dd if=/dev/dsk/c0t0d0s2 of=disk.img ...
>> > is not going to go over so well, given that there's no disk label and
>> > hence no slices.
>>
>> > I guess what I am looking for is an equivalent to Linux's /dev/sda
>> > device that accesses the whole disk.
>>
>> /dev/rdsk/diskblahlblahs2 (note the s2. s2 = entire disk)
> But only if there's a disk label that says so. s2 spans the entire
> disk only by convention. If there's no label, the system won't know
> how big s2 is. And there's no label on my disk...

If there's really no label, I don't think Solaris sparc will
let you open the disk, except in a special mode in order to
write a label.

(Worse still, if there is a valid label but it's seriously
incompatible with the disk, Solaris sparc won't even let you
open the disk in the special mode to relabel it - you have to
cart it off to another system and OS to blow away the confusing
label first.)

> That's different from Linux where /dev/sda is its own device and will
> thus always address the entire disk, whether it's partitioned or not.

Solaris x86 has the /dev/rdsk/diskblahlblahp0 devices, which
are the whole physical disk regardless of any labeling.
It is rather unfortunate that Solaris sparc does not have
the p0 devices.

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

Andrew Gabriel <andrew@cucumber.demon.co.uk> wrote:
> In article <45d6b5fc-536f-4138-8e19-5d42ed1ac2d5@k13g2000prh.googlegroups.com>,
>        Markus <mman75@gmail.com> writes:
>> On Sep 11, 3:06?pm, Cydrome Leader <prese...@MUNGEpanix.com> wrote:
>>> Markus <mma...@gmail.com> wrote:
>>>
>>> use the dd command.
>> Which is exactly what I am suggesting in my original message.
>>> > I haven't tried this yet (for lack of a place of storing the disk
>>> > image to), but I would imagine that trying to do
>>> > ?dd if=/dev/dsk/c0t0d0s2 of=disk.img ...
>>> > is not going to go over so well, given that there's no disk label and
>>> > hence no slices.
>>>
>>> > I guess what I am looking for is an equivalent to Linux's /dev/sda
>>> > device that accesses the whole disk.
>>>
>>> /dev/rdsk/diskblahlblahs2 (note the s2. s2 = entire disk)
>> But only if there's a disk label that says so. s2 spans the entire
>> disk only by convention. If there's no label, the system won't know
>> how big s2 is. And there's no label on my disk...
> 
> If there's really no label, I don't think Solaris sparc will
> let you open the disk, except in a special mode in order to
> write a label.
> 
> (Worse still, if there is a valid label but it's seriously
> incompatible with the disk, Solaris sparc won't even let you
> open the disk in the special mode to relabel it - you have to
> cart it off to another system and OS to blow away the confusing
> label first.)

Hmm. I've seen somethis with unified LUNs from a SAN that were not 
formatted (on the san) and had old solaris stuff on them. Solaris would 
never see the correct disk size.

>> That's different from Linux where /dev/sda is its own device and will
>> thus always address the entire disk, whether it's partitioned or not.
> 
> Solaris x86 has the /dev/rdsk/diskblahlblahp0 devices, which
> are the whole physical disk regardless of any labeling.
> It is rather unfortunate that Solaris sparc does not have
> the p0 devices.

Ok so the S2 stuff on sparc is only accurate IF the disk lable is good. if 
it's junk, you lose. Interesting.

On Sep 16, 8:55 pm, Cydrome Leader <prese...@MUNGEpanix.com> wrote:
> Andrew Gabriel <and...@cucumber.demon.co.uk> wrote:
> > In article <45d6b5fc-536f-4138-8e19-5d42ed1ac...@k13g2000prh.googlegroups.com>,
> >        Markus <mma...@gmail.com> writes:
> >> On Sep 11, 3:06?pm, Cydrome Leader <prese...@MUNGEpanix.com> wrote:
> >>> Markus <mma...@gmail.com> wrote:
>
> >>> use the dd command.
> >> Which is exactly what I am suggesting in my original message.
> >>> > I haven't tried this yet (for lack of a place of storing the disk
> >>> > image to), but I would imagine that trying to do
> >>> > ?dd if=/dev/dsk/c0t0d0s2 of=disk.img ...
> >>> > is not going to go over so well, given that there's no disk label and
> >>> > hence no slices.
>
> >>> > I guess what I am looking for is an equivalent to Linux's /dev/sda
> >>> > device that accesses the whole disk.
>
> >>> /dev/rdsk/diskblahlblahs2 (note the s2. s2 = entire disk)
> >> But only if there's a disk label that says so. s2 spans the entire
> >> disk only by convention. If there's no label, the system won't know
> >> how big s2 is. And there's no label on my disk...
>
> > If there's really no label, I don't think Solaris sparc will
> > let you open the disk, except in a special mode in order to
> > write a label.
>
> > (Worse still, if there is a valid label but it's seriously
> > incompatible with the disk, Solaris sparc won't even let you
> > open the disk in the special mode to relabel it - you have to
> > cart it off to another system and OS to blow away the confusing
> > label first.)
>
> Hmm. I've seen somethis with unified LUNs from a SAN that were not
> formatted (on the san) and had old solaris stuff on them. Solaris would
> never see the correct disk size.
>
> >> That's different from Linux where /dev/sda is its own device and will
> >> thus always address the entire disk, whether it's partitioned or not.
>
> > Solaris x86 has the /dev/rdsk/diskblahlblahp0 devices, which
> > are the whole physical disk regardless of any labeling.
> > It is rather unfortunate that Solaris sparc does not have
> > the p0 devices.
>
> Ok so the S2 stuff on sparc is only accurate IF the disk lable is good. if
> it's junk, you lose. Interesting.

in solaris the format command should be able to restore you label.

type format
select you drive
then type backup and pray.

don