Well, it appears that I truly am outta luck. Thanks to Reggie Stuart
and Kevin Graham for taking the time to reply. As Kevin's reply shows, I
shot myself in the foot. Oh well, chalk another one up in the "tired,
overworked sysadmin shoots self in foot" category. Fortunately this is
just a test server and I can simply recopy the data from the production
server this weekend...
"You have moved your mouse. Windows NT must be rebooted for the change to
take effect. Reboot now (Y/N)?"
Part of creating a raid5 set is initializing it. Had you not already
created it, this would have been of use:
-k For RAID5 metadevices, informs the driver that it is
not to initialize (zero the disk blocks) due to exist-
ing data. Only use this option to recreate a previously
created RAID5 device.
However, I would imagine your data is unrecoverable now that you've
already created the raid5 set.
Sorry I don't have any good news, but since you are working this issue,
thought I might mention this:
I had a very similar problem a few months back, but (thankfully) we were
using veritas. In that system, if you can identify the disks, and tell
what group/plex they belong to, they automagically put themselves back
DiskSuite is not the tool for 140G of data. Accident waiting to happen
(sorry, it already has happened). Try to upgrade the bigger disk setups to
Not a dig, or a sales pitch, just a little ammo to take to the PO
---------------------- Forwarded by Kevin Buterbaugh/Nashville/BSSBNOTES on
09/22/2000 09:58 AM ---------------------------
Sent by: firstname.lastname@example.org
Subject: Solaris 2.7 / DiskSuite 4.2 question...
I know the answer to this is probably, "sorry, you're outta luck." I
already know that this is not supported by Sun. However, I figure if
there's a way to do this, someone on the list will know how...
I have an E250 that was purchased to test a new version of our
application software (a product called Vista). I installed Solaris 2.8 on
the server, along with DiskSuite 4.2 and the application software. I used
DiskSuite to create metadevices for all my filesystems, created the
filesystems, then copied my production data (140+ GB) from my production
server to the E250 using rcp.
Now I find out that our application software is not yet certified
under Solaris 2.8. I was therefore forced to reinstall the E250 with
Solaris 2.7. I also (re)installed DiskSuite 4.2 and recreated my
metadevices with the exact same disk or disks that I had used under Solaris
2.8. Here's the relevent portions of the output of "metastat -p":
d11 -r c2t4d0s0 c2t5d0s0 c2t6d0s0 -k -i 128b
d9 1 1 c0t0d0s0
d10 1 1 c0t8d0s0
d12 1 1 c0t9d0s0
d13 1 1 c0t10d0s0
d14 1 1 c0t11d0s0
d15 1 1 c0t12d0s0
d16 1 3 c2t1d0s0 c2t2d0s0 c2t3d0s0 -i 128b
d17 1 9 c1t5d0s0 c1t8d0s0 c1t9d0s0 c1t10d0s0 c1t11d0s0 c1t12d0s0 c1t13d0s0
c1t14d0s0 c1t15d0s0 -i 128b
I then attempted to remount the filesystems. I had 9 filesystems, 8
of which I got back (I can see all the data in those filesystems). The one
that I was not able to even remount successfully was metadevice d11, the
only filesystem I created in a RAID 5 metadevice (it has the application
itself, so they wanted it protected). I had added appropriate entries to
/etc/vfstab, but when I try to mount the filesystem /vista3 to md11, I get:
x4test/usr/local/bin: mount /vista3
mount: /dev/md/dsk/d11 is not this fstype.
Of course, my question is "Is there any way to get that data back, or
does the act of creating a RAID 5 metadevice in DiskSuite (I used metatool)
blow it away?" If I can't get it back, I've got to recopy all 140+ GB of
data to keep it all in sync. Thanks for any suggestions...
"Failure is not an option. It's a standard feature of every Microsoft
U BEFORE POSTING please READ the FAQ located at
. and the list POLICY statement located at
A To submit questions/summaries to this list send your email message to:
A To unsubscribe from this list please send an email message to:
E and in the BODY type:
R unsubscribe sun-managers
. unsubscribe sun-managers email@example.com
L To view an archive of this list please visit:
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:18 CDT