----Synopsis----

A hard disk from a macintosh computer failed resulting in a white screen at boot time. The owners were told that the drive was damaged and it was replaced. The faulty drive was imaged, the hfsplus boot block was repaired using the alternate boot block and the filesystem was repaired, allowing for the recovery of all of the owners personal data.

----Imaging----

The 2.5 inch hard disk was connected to a power supply and a USB to SATA interface which was then connected to a computer running Ubuntu linux.

$tail -f /var/log/messages

The view of the /var/log/messages showed numerous read errors as the drive was being recognized by the kernel. After several attempts at power cycling the drive, it was recognized in /proc/partitions as the correct devices (/dev/sdc /dev/sdc1 and /dev/sdc2). Imaging of /dev/sdc2 was started several times, but the drive failed after a few moments. The imaging of the entire drive (/dev/sda) was started and much more data was recovered in the first few hours. The output was at an average speed of 12 MB/s.

$sudo ddrescue -v /dev/sdc image log

The drive powered off intermittently over the first 8 hours of imaging. Recover was restarted in reverse and using direct disk access, resulting is a much slower rate of 368 Kb/s.

sudo ddrescue -vRDd -r 99 /dev/sdc image log

However, the drive sustained this without powering off over the remaining recovery. Most of the 120 gigs were recovered in the first five days of recovery. About 50 Mb of the remaining 800 Mb to be imaged were recovered over two more subsequent days. Only about 750 Kb of the total 120 Gigs were unrecovered.

----Partition table----

The partition table on the image was intact.

$sudo parted image unit b print
Model: (file)
Disk /media/disk-1/doug1/image: 120034123776B
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 20480B 209735679B 209715200B fat32 EFI System Partition boot
2 209735680B 119899885567B 119690149888B Apple_HFS_Untitled_1

The filesystem was not mountable.

$ sudo mount -o loop,offset=209735680 image mnt/
mount: you must specify the filesystem type
$ sudo mount -o loop,offset=209735680 image mnt/ -t hfsplus
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

The image was backed up and all work was performed on the copy. Testdisk was run on the image:

$ sudo testdisk image

The advanced filesystem utilities were used and the Volume Header (superblock) was found to be bad.

Volume header
Bad

Backup volume header
HFS+ OK

Sectors are not identical.

[ Quit ] [Backup BS] [ Dump ]
Return to Advanced menu

The backup Boot Sector was used to correct the problem.

Testdisk was then quit and the filesystem was mounted.

$sudo mount -o loop,offset=209735680 image mnt/ -t hfsplus
$ ls mnt

ls: reading directory mnt: Input/output error
Applications bin Desktop DB dev eBookUSBDriver 2.pkg eBookUSBDriver 4.pkg eBookUSBDriver.tar etc mach
automount cores Desktop DF Developer eBookUSBDriver 3.pkg eBookUSBDriver.pkg EndNote X1 Library mach.sym

The /home folder was absent. The image was unmounted and the loop device was associated with the partition on the image:

sudo losetup /dev/loop0 image -o 209735680

The filesystem was repaired:

sudo fsck.hfsplus /dev/loop0

sudo fsck.hfsplus -y /dev/loop0

sudo fsck.hfsplus -r /dev/loop0

The filesystem was mounted and the pertinent files were recovered from the lost+found directory. The owners of the drive report that 100 per cent of their data was recovered.