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 stuff Kangaroo's Homepage (czech)