I have 2 drives from a dead Ultra 10 that were mirrored using Veritas
3.1.1 on Soalris 8. The root drive was encapsulated using the default
install encapsulation and mirrored. An additional Veritas volume was
created and mirrored. I can hook the drives to another system and can
access all the encapsulated file systems. But I need to recover the
data off the Veritas volume.

If I hook the drive to another system running Veritas will I somehow
be able to mount the veritas volume on it? I don't have the stuff to
do this in house but could set it up with some effort but don't want
to go down that road unless I have some idea whether and/or how it
will work.

Any hints on how best to accomplish this would be greatly appreciated.

Thanks,
Ron

In comp.unix.solaris Ron Albright <moron@pobox.com> wrote:
> I have 2 drives from a dead Ultra 10 that were mirrored using Veritas
> 3.1.1 on Soalris 8. The root drive was encapsulated using the default
> install encapsulation and mirrored. An additional Veritas volume was
> created and mirrored. I can hook the drives to another system and can
> access all the encapsulated file systems. But I need to recover the
> data off the Veritas volume.

> If I hook the drive to another system running Veritas will I somehow
> be able to mount the veritas volume on it? I don't have the stuff to
> do this in house but could set it up with some effort but don't want
> to go down that road unless I have some idea whether and/or how it
> will work.

Yes. It would be best if the other volume were in a disk group other
than 'rootdg'. Then you could simply import the dg, start the volume,
and mount it up. (Do you know if it's a UFS or VxFS filesystem? You'd
need VxFS also if that were on the disk).

However it's possible that everything on the old system was just in
rootdg. That's a little more difficult. Also, you traditionally import
*all* the disks in a disk group simultaneously, not just one or two of
them. First attach the disks and see what dg if any is on them with
'vxdiks -o alldgs list'.

If it's not rootdg, just import it.

If it is and you have all the disks attached, try this. Identify the
diskgroup ID on the newly attached disks with 'vxdisk -s list'. Then
import with...

vxdg -C -n olddg <diskgroup ID string>

If you don't have all the disks in the diskgroup, you'd have to force
the import with -f and hope that the volumes you need are present on the
disks you've imported. When done, attempt to start the volumes you want
with 'vxvol start <vol>' and then try to fsck/mount them.

Good Luck!

Personally, if I had a spare machine, but no other installation of VxVM
running, I might try instead to get the old installation booted rather
than do a new VxVM install.

--
Darren Dunham ddunham@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

On Thu, 08 Jan 2004 18:09:46 GMT, Darren Dunham
<ddunham@redwood.taos.com> wrote:

>
>Personally, if I had a spare machine, but no other installation of VxVM
>running, I might try instead to get the old installation booted rather
>than do a new VxVM install.

That was my first idea too but I don't have an ULTRA 10. I tried
booting the drives in an ULTRA 5 but it couldn't find the kernel and
asked me for a file to boot. I'm not versed in the details of the
Solaris boot process. I'm assuming the hardware differences require
different kernels. Are there any tricks I can use to boot them on the
5?

Thanks much for the info.
Ron
My email isn't airmail.
Ron

In comp.unix.solaris Ron Albright <moron@pobox.com> wrote:
> On Thu, 08 Jan 2004 18:09:46 GMT, Darren Dunham
> <ddunham@redwood.taos.com> wrote:

>>
>>Personally, if I had a spare machine, but no other installation of VxVM
>>running, I might try instead to get the old installation booted rather
>>than do a new VxVM install.

> That was my first idea too but I don't have an ULTRA 10. I tried
> booting the drives in an ULTRA 5 but it couldn't find the kernel and
> asked me for a file to boot. I'm not versed in the details of the
> Solaris boot process. I'm assuming the hardware differences require
> different kernels. Are there any tricks I can use to boot them on the
> 5?

Nope. In fact, the U5 and the U10 are the same motherboard. If you're
having booting issues, I doubt it has anything at all to do with the
hardware.

--
Darren Dunham ddunham@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

On Thu, 08 Jan 2004 18:09:46 GMT, Darren Dunham
<ddunham@redwood.taos.com> wrote:

>If it is and you have all the disks attached, try this. Identify the
>diskgroup ID on the newly attached disks with 'vxdisk -s list'. Then
>import with...
>
>vxdg -C -n olddg <diskgroup ID string>

I think you mean 'vxdg -C -n olddg import <diskgroup ID string>'


Regards,

Tom Hall <thall777@dca.net>

In comp.unix.solaris Tom Hall <thall777@dca.net> wrote:
> On Thu, 08 Jan 2004 18:09:46 GMT, Darren Dunham
> <ddunham@redwood.taos.com> wrote:

>>If it is and you have all the disks attached, try this. Identify the
>>diskgroup ID on the newly attached disks with 'vxdisk -s list'. Then
>>import with...
>>
>>vxdg -C -n olddg <diskgroup ID string>

> I think you mean 'vxdg -C -n olddg import <diskgroup ID string>'

That would work much better!

--
Darren Dunham ddunham@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

On Fri, 09 Jan 2004 00:53:36 GMT, Darren Dunham
<ddunham@redwood.taos.com> wrote:

>
>Nope. In fact, the U5 and the U10 are the same motherboard. If you're
>having booting issues, I doubt it has anything at all to do with the
>hardware.

Aren't I the friggin idiot. After reading this I went back and double
checked what I had been doing. I was trying to boot them in a Blade
100. I stuck'em in a Ultra 5 and it booted right up. I guess a pizza
box isn't always just a pizza box.

Again, thanks for the help.
--
My email isn't airmail.
Ron

In article <1l3rvv0f2dqutc2cqrn63bcoo7cro3ctsu@4ax.com>,
Ron Albright <greenbird@pobox.airmail.com> did thusly spew forth:
>I have 2 drives from a dead Ultra 10 that were mirrored using Veritas
>3.1.1 on Soalris 8. The root drive was encapsulated using the default
>install encapsulation and mirrored. An additional Veritas volume was
>created and mirrored. I can hook the drives to another system and can
>access all the encapsulated file systems. But I need to recover the
>data off the Veritas volume.

Ok... The above is not 100% crystal clear what you're recovering from. However,
assuming the data volume you're after is a simple mirrored pair and not a
concat or a stripe, AND the data volume is UFS, you should be able to simply
mount the /block device associated with the disk's public region. You can find
the first the slice that the public region occupies by doing something like:

# prtvtoc -s /dev/rdsk/c4t15d4s2
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
2 5 01 0 142147584 142147583
3 15 01 0 16384 16383
4 14 01 16384 142131200 142147583

You are looking for the partition tagged "14". In the above example, this is
slice 4. Given the above cXtYdZ information, you could verify the mountabil-
ity of the public region slice by typing `fstyp /dev/rdsk/c4t15d4s4`. It
should return "ufs". Assuming the "dirty" flag is not set, you would then
simply be able to type `mount /dev/dsk/c4t15d4s4 /mnt`. If the dirty flag is
set, you'll have to fsck the partition, first, then mount. Your data should
then be fully available to you at "/mnt".

-tom

* Ron Albright wrote:
> I have 2 drives from a dead Ultra 10 that were mirrored using Veritas
> 3.1.1 on Soalris 8. The root drive was encapsulated using the default
> install encapsulation and mirrored. An additional Veritas volume was
> created and mirrored. I can hook the drives to another system and can
> access all the encapsulated file systems. But I need to recover the
> data off the Veritas volume.

It depends a lot on what ended up on which disk. It sounds to me like
you have two drives from a four drive setup: the original setup being
a pair of system disks, which had been encapsulated and mirrored, and
then a pair of other disks, each of which had one half of a mirrored
volume on them. If that's the case then the non-system disk *ought*
to have a single public region on it (which will be a partition with
tag 14), and in that will be a UFS filesystem, which you can
(carefully) recover.

If what you have is a mirrored pair of disks which had an encapsulated
root filesystem and then some other volume on them, then God help you:
this is the kind of setup that gets VxVM a bad name. I think in that
case the first thing is to look at the partitioning very closely (it
should be identical for each disk, so just use one): what you should
find is a bunch of partitions for the encapsulated stuff - root, any
other filesystems, and swap. These partitions should not use the
whole disk. Then there a couple of partitions for the VxVM private
area (tag 15?) and the VxVM public area (tag 14?). The private area
will probably be somewhere at the end of swap, and the public area
will overlap all the others, I think (it will be essentially the whole
disk).

The data from the volume you are looking for is somewhere in the bit
of the public which isn't covered by the other slices. If you are
lucky it's immediately following the end of the last other slice, so
you could do a couple of things:

* make a new slice which covers the part of the public slice not
covered by any other slices (other than s2 of course), and see if
there is a filesystem in it using fstyp &c. YOu will probably need
to reuse a slice to do this, so make *really* sure you can go back
to how the disk was: *write the partitioning down!*. This is a fairly
perilous operation.

* work out the offset of the public region where it starts not
overlapping other slices. Use dd to recover all the data from that
to the end of the disk to some safe place. Make a suitable
partition on a scratch disk, dd the data onto that, and see if
there's what looks like a filesystem theee.

Both of these are fairly hairy.

> If I hook the drive to another system running Veritas will I somehow
> be able to mount the veritas volume on it? I don't have the stuff to
> do this in house but could set it up with some effort but don't want
> to go down that road unless I have some idea whether and/or how it
> will work.

Yes, I think this will work (if they are a pair, rather than 2 of 4)
You should probably attach *both* disks, and VxVM will find them.
There will be some issues because they'll have a rootdg on them, but
you can import a dg renaming it in the process, and I think this will
work. I'm fairly sure that the VxVM manuals cover situations like
this.

--tim