Iomega Raid JBOD crash & recovery

Friend of mine had a problem with Iomega double disk external raid drive
Ultramax Plus.
Dangerous hardware JBOD
-----------------------
Since we believed, it's a controller problem and I had the same device, we
decided just to swap drives to save data. After connecting to Mac OS X
10.6.8, system asked to Initialize the drive -- it couldn't see the data
anymore! Once I swaped my original disks back to the device, system asked to
Initialize the drive again! Ooops! None of the disks worked!
// Will never do this again and never buy Iomega drive again. Even 'cause
// Iomega is not a company any more. It was bought by Lenovo, so no user
// support. Eeek.
Both the drives were set to JBOD mode, which means the two drives appear as
a single drive of double size for the system. JBOD means "Just a Bunch Of
Disks", which should mean, the data is just concatenated. End of data on one
drive should be start of the data on the another.
Inside of both the devices we can see processor marked Oxford
Semiconductors "oxufs936DS-fbag", which is USB 2, FireWire 800 and eSata
interface for Sata II drives providing the hw RAID. It's used in many
external drives, but no real public documentation is provided for the chip
(and company bought by plx). But it seems to me, that the device somehow
remembers which disks were used last time and if it detects change, it just
makes a new array, maybe writing over first blocks. Ugly. Very ugly.
// http://plxtech.com/files/pdf/apps/ExpApp69_OXUFS936x_Storage.pdf
Solution; Recovery of partition table
--------------------------------------
After long experimenting, command line tool testdisk helped to recovery the
partition table on both drives quite easily:
testdisk /dev/disk2
...
1 P EFI System 40 409639 409600 [EFI System Partition]
2 P Mac HFS 409640 1953084151 1952674512 [Untitled]
...
Testdisk can be installed using macports and is multi-platform.
port install testdisk
// http://www.cgsecurity.org/wiki/TestDisk
Recovery of the drive itself
----------------------------
// good, in detail guide:
// http://arstechnica.com/civis/viewtopic.php?t=1197911
1] determine the disk name:
disktool list
our drive is /dev/disk2 (the other is disk0, mounted /, the main system
disk; disk1 is a spare 4TB disk for moving the data, mounted on
/Volume/savior)
Better than /dev/disk2 is to use a "raw disk access", which is /dev/rdisk2
-- this somehow bypass system caches. And reads two times faster. (On
error we don't want the system to stuck, just to skip the data. Non-raw
drive stucked the whole system after 3 of 4 TB -- after this point
system wasn't talking to disk any more in all the tries.)
2] Create an image of the drive (4TB JBOD).
2a] Since there are some problems, when even touching the filesystem makes
the disk freeze, disable automount:
disable automount (as root)
launchctl unload
/System/Library/LaunchDaemons/com.apple.diskarbitrationd.plist
2b] using tool ddrescue (part of macports collection) make a copy of the
disk.
unlike of dd, ddrescue first reads the data which can be read easily and
ignores data with errors. then it goes to problematic parts in multiple
passes and tries to recovery it as well.
// http://www.gnu.org/software/ddrescue/ddrescue.html
ddrescue is a part of port system:
port install ddrescue
// howto install port system
cd /Volume/savior
ddrescue -P /dev/rdisk2 disk-backup-image.img ddrescue.log
where:
-P is just fancy switch to show data samples during backup
disk-backup-image.img is where data will be put and
ddrescue.log is a log of ddrescue, which helps it to continue, where it
stopped, if you break the process
man ddrescue
2c] wait some 2 days for 4 TB drive and FireWire 800.
Enough for wedding or visiting parents.
If you need to stop the process, you can just pres CTRL+C, and continue
later on with the same command.
REMARKS
-------
1] if you want to make the exact copy of separate disk drives from the
box, do the following:
Insert the drive into the computer or external enclosure and under
Terminal do:
dd if=/dev/diskX of=/tmp/whatever-disk1.img
dd if=/dev/diskY of=/tmp/whatever-disk1.img
Where diskX and diskY are disk names guessed from command (mac os x):
disktool list
each of the file will have the size of original drive and will be it's
exact copy. It will take quite a lot of time, depending on size and speed
of disks.
After unsuccesful experiment you can write the data back to disk using dd
in reverse manner.
2] raw image mounts like this under Mac OS X:
hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount
rajdik-top.img
3] JBOD disks could be joint under linux tool mdadm, using loopback
devices (loconfig) -- no success for me (supposed offset problem with
loopback device), but could be a hint for someone
// http://www.linuxquestions.org/questions/linux-server-73/mdadm-assemble-raid5-with-loopback-mounted-disk-images-715343/
// http://arstechnica.com/civis/viewtopic.php?f=16&t=80250
EOF
Comments requested
~~~~~~~~~
Binary Sxizophreny - index of comp related stuffKangaroo's Homepage (czech)