In my arsenal of USB2-attached hard drives, there’s a 500GB LaCie “Big Disk” USB2. This has been running for a while and seemed OK, although the USB2 chipset does get a little confused when there’s a sudden power loss. Sadly it died a fortnight ago – dmesg pointed out to me that the USB had disappeared, and upon investigation it looked like complete power loss or at least drive failure. The data wasn’t critical (I used it as a scratchpad) but curiosity got the better of me and I decided to attempt retrieval of the data.
Inside these “Big Disk” units are invariably two smaller drives – LaCie’s attempt to sell off bigger-than-consumer space using commodity disks. In this case, there were two Samsung drives of 250GB apiece (SP2514N). I have a handy USB-IDE interface which I used to plug in each drive in turn:
- Disk 1 (Master) obviously had a partition table on it with a single 500GB ext3 partition defined (yes, it’s a 250GB disk!). Familiar, maybe this isn’t a dead loss!
- Disk 2 spun up, detected, but no partition table.
My USB-IDE thingy doesn’t allow me to connect two disks at once so I figured I’d put it down for a week while I purchased a big enough disk to recover any data to.
The big question at this stage was whether the data was striped (RAID0) or whether disk2 was “welded onto the end” of disk1’s partition.
Once I’d got a big enough disk to recover data to, the first thing I did was get all the data off the disks using:
dd if=/dev/sdc of=disk1.bin bs=1M
and the same for the second disk (although sending it to disk2.bin in this case). That left me with two 250GB files, and I used losetup on disk1.bin (the one with the partition table):
losetup /dev/loop1 disk1.bin
That in turn gave me:
Device Boot Start End Blocks Id System
/dev/loop1p1 1 60802 488392033+ c W95 FAT32 (LBA)
So far so good, but it’s still just half the disk I’m mounting (and I’m pretty convinced the partition was ext3, not fat32!). By this time I wasn’t in the mood to try and work out striping (and if it’s needed in the future use mdadm or lvm), so just went for the theory that disk2 was lumped onto the end of disk1, making an uberimage through use of something as simple as ‘cat’:
cat disk2.bin >>disk1.bin
I mounted the loopback again, and tried to get to the partition:
# mount /dev/loop1p1 /mnt
mount: special device /dev/loop1p1 does not exist
Bollocks.
Enter your local friendly Interweb maillist, and Peter informed me that the fdisk partition was most likely a red herring and pointed me at the losetup ‘-o’ option which would skip the partition table straight to partition 1. Couple that hint with this info via Google and we’re in business using parted and offsets:
# parted disk1.bin
GNU Parted 1.7.1
Using /media/disk-1/disk1.bin
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit
Unit? [compact]? B
(parted) print
Disk /media/disk-1/disk1.bin: 500118700031B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32256B 500113474559B 500113442304B primary ext3 lba
(parted) quit
# mount -o loop,ro,offset=32256 disk-1.bin /mnt/disk1
# cd /mnt/disk1
# ls
lost+found junkheap Graphics
# rsync...
You get the idea – it’ll take a while. Mine’s still not finished and of course some data may be mangled so probably worth using –ignore-errors in your rsync as well.
So to summarise:
- If your LaCie “Big Disk” fails and it’s not the PSU or one of the disks, it’s worth popping the disks out and attempting to weld the two disk images together.
- The exact model this worked on was the USB2 500GB “Big Disk” configured in JBOD mode – I can’t tell you the model number because helpfully it’s not printed anywhere on the chassis or label.
- You need at lot of disk space – a pile for the image (which will be the size of the “Big Disk” even if it’s not full), and a pile of space to recover the data to. I got a 1TB disk from our local computer shop.
- All this was done using my little eeePC which is running Ubuntu Hardy Heron.
