At 14:21 -0700 2004-06-21, Aron Roberts wrote:
> Is there a way to break a mirrored (RAID Level 1) disk array,
>created using Disk Utility in Mac OS X?
>
> We're running Mac OS X Server 10.3.4 on a first-generation XServe.
>Following a physical move of this machine to the new campus Data
>Center,a colleague found that a drive bay handle was left in an
>extended state (see below).
>
> Now, Status Monitor, Disk Utility, and 'diskutil checkRAID' all
>report that the RAID array is "degraded" - presumably, no longer in
>sync.
>
> Before attempting to rebuild the existing array, do you happen to
>know if is possible to simply 'break' the array, resulting in two
>normal (non-RAIDed) volumes? RAID software from other OS vendors
>and even third-party vendors for the Mac OS provides this feature,
>but neither Disk Utility nor the command-line 'diskutil' utility
>seem to offer this option.
Since this message was first posted to MAGNet, and hence archived
to the web courtesy of L&S-CR, then indexed by Google, we've already
had two queries from others at the University of Texas and Eastern
Oregon University who have experienced a similar problem.
Thus, for anyone else, on campus or otherwise, who might encounter
this problem, here's a follow-up:
We ended up rebuilding the mirrored array in place via 'diskutil
repairMirror ...' rather than breaking the array, as described in
more detail below. This operation ran unattended; took about two
hours to rebuild the array on two, 120 GB disks; and appears to have
concluded successfully, with no errors occurring in the six week
period after the array was rebuilt.
You can first run 'diskutil list' to identify the appropriate
device nodes for each of the disks in the mirror, and of the RAID
array itself. You can also run 'diskutil checkRAID' to identify the
RAID array slice number. After doing so, you can plug those three
device nodes and the slice number into the appropriate arguments to
the 'diskutil repairMirror command. (Remember that the device nodes
- at least when they are expressed as values like "diskn", where "n"
is a digit - don't necessarily correspond to the XServe's physical
drive bay numbers.)
As always, your mileage may vary, so it'd be prudent to first make
sure you have a fully-restorable backup of the relevant volume, as we
did in this instance.
Finally, the diskutil command also offers a 'destroyRAID' option,
whose function is to "Destroy an existing RAID set", according to
diskutil's 'man' page. However, it wasn't clear from that brief
description whether that option might also destroy data on the
volumes in the RAID array, so we decided to first try rebuilding the
array. (In a worst case scenario, that option also might be worth
exploring as a way to break the array.)
Aron Roberts
Workstation Software Support Group
-- We rebuilt [our server's] mirrored RAID set for the Boot volume this morning. Formerly, this RAID was listed as "Degraded". After the rebuild, it's now listed as "Running", both by Disk Utility and via the 'diskutil' command: % diskutil checkRAID RAID SETS --------- [...] Name: Boot Unique ID: Bootadf4c236b43f11d695bc000393a67d82 Type: Mirror Status: Running Device Node: disk5 ------------------------------------------------------------- # Device Node Status ------------------------------------------------------------- 0 disk0 OK 1 disk2 OK ------------------------------------------------------------- The command we used to rebuild the array, synchronizing the contents of disk0 onto disk2, was: sudo diskutil repairMirror disk5 1 disk0 disk2 where "disk5" is the device node for the mirror [as shown in the "Device Node" entry from 'diskutil checkRAID', above; the array's device node is also obtainable via 'diskutil list'], "1" is the slice of the array (stored on disk2) to be replaced [as shown in the '#' column in the results from 'diskutil checkRAID', above] and disk0 and disk2 represent the OK disk and the disk to be rebuilt or replaced in the array, respectively [with these drive device node names obtained from 'diskutil list']. See <http://docs.info.apple.com/article.html?artnum=106987> for details ... Rebuilding the mirrored array using these two ~120 MB drives took about two hours, and ran unattended. ------------------------------------------------------------------------ The following was automatically added to this message by the list server: For information about MAGNet, its meetings and events, and its mailing list, including information on subscribing and unsubscribing, see the MAGNet Web site at <http://magnet.berkeley.edu/>.Received on Thu Jul 8 11:45:41 2004
This archive was generated by hypermail 2.1.8 : Thu Jul 08 2004 - 11:45:41 PDT