The Iomega Stor Center is a common NAS device used in Irish workplaces and homes. It is fairly robust, intuitive to use and can be easily configured to work with any network.
But, like any storage device, it is prone to failure – like one Dublin-based software development company discovered last week.
They were using their Stor Center ix2 as a surrogate server to store everything from PDF files to back-ups of their C++ and Java files which they use to write their software.
Last week, one user could not access the shares and attributed it to a glitch. Then his colleagues discovered they could not even see the network shares anymore. They went to investigate it further. The indicator warning light on their Iomega StorCenter was flashing. They logged into the management console of the device. It was then they discovered that one of the disks, disk 0, was offline. As the ix2 is only a two bay device, it can only be set-up in RAID 0, RAID 1 or JBOD. This device was setup in RAID 0 which meant that half of their data was on a drive which had gone offline. They removed disk 0 and slaved it to a PC system but it was totally dead. In terms of solutions, they had run out of road.
They delivered the two Seagate ES.2 drives to us. Our diagnostics revealed that Disk 1 was in perfect health but Disk 0 had a failed PCB (failed inductor chips).
ES.2 drives use Seagate’s F3 architecture. This means that the ROM on the PCB holds unique adaptive information needed for the operation of the drive.
The drive was brought to our rework station. Here our technicians used hot-air to carefully remove the drive’s ROM chip. (De-soldering such a delicate chip can be messy operation). We had an ES.2 donor board already in stock. The removed ROM chip was then carefully micro soldered onto the donor PCB (whose original ROM chip had been removed) . The said PCB was then fitted onto the drive.
The drive spun up with a healthy reassuring spin. Now it was time to image both the drives. The imaging process took 3.5 hours to complete.
Using both drive images, our technicians now set about to rebuild the RAID 0 array. Using a hex editor they determined the exact parameters of the array such as disk order, block off set and stripe size. The RAID rebuild took a couple of hours to complete.
Finally, the volume was mountable again. All of their Java, Pyhton and C++ code libraries and PDFs (all of which had taken months to compile) were accessible once again. Result: a very happy software development team who not have to cover old ground in re-writing code and PDF manuals.