Mostly Technical

A few weeks ago I plugged the external USB hard drive that holds my photo library into my Mac, and was greeted with the following message:

“The disk you inserted was not readable by this computer.”

Bummer. As it happened, I didn’t have an up-to-date backup of the drive, having made some recent updates. I really needed to recover the contents of the drive. I tried the drive in another Mac, and got the same message. I tried it in a Windows machine, and got a message about an error with the drive.

I plugged it back into the Mac and had a look at Disk Utility. It showed the drive in the left pane, but with no associated volumes. On the First Aid tab, the Verify Disk and Repair Disk items were grayed out. In the disk info section at the bottom, the following telltale appeared: “Partition Map Scheme: Unformatted”. It was clear that the partition table had been corrupted somehow.

I gave up on the GUI tools and switched to diskutil, which is OSX’s tool to manage disks, volumes, and partitions.

The list command shows the available drives:

[21:07:16] mini-me ~ $ diskutil  list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS MacintoshHD             119.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.5 TB     disk1
   1:                        EFI                         209.7 MB   disk1s1
   2:                  Apple_HFS BigMedia                1.5 TB     disk1s2
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *1.0 TB     disk2

Lines 13-15 (disk2) represent the drive in question. Note that there are no partition types or volume names, nor are there any partitions. diskutil has several repair verbs. One of them, repairDisk, exists specifically to fix a busted partition map:

Repair the components of a partition map of a disk

I am certain that this drive used to be partitioned using the GUID partition scheme (the default under OSX), so answered yes to the confirmation question:

[21:08:23] mini-me ~ $ diskutil repairDisk /dev/disk2
Nonexistent, unknown, or damaged partition map scheme
If you are sure this disk contains a (damaged) APM, MBR, or GPT partition map,
you can hereby try to repair it enough to be recognized as a map; another
"diskutil repairDisk /dev/disk2" might then be necessary for further repairs
Proceed? (y/N) y
Partition map repair complete; you might now want to repeat the
verifyDisk or repairDisk verbs to perform further checks and repairs

That seems to have fixed it; diskutil now recognized the two partitions from the external drive:

[21:08:52] mini-me ~ $ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS MacintoshHD             119.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.5 TB     disk1
   1:                        EFI                         209.7 MB   disk1s1
   2:                  Apple_HFS BigMedia                1.5 TB     disk1s2
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI                         209.7 MB   disk2s1
   2:                  Apple_HFS TimeMachine             150.0 GB   disk2s2
   3:                  Apple_HFS Mercury                 849.7 GB   disk2s3

To confirm that the partition really was restored, mount up the disk:

[21:09:47] mini-me ~ $ diskutil mountDisk /dev/disk2
Volume(s) mounted successfully

[21:09:53] mini-me ~ $ mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk2s2 on /Volumes/TimeMachine (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk2s3 on /Volumes/Mercury (hfs, local, nodev, nosuid, journaled, noowners)

I manually checked the contents of the two partitions, and they appeared to be correct. All the files were readable and I didn’t notice anything missing. Disaster averted!

If diskutil had been unable to recover my files, there are some alternatives:

• TeskDisk: Data recovery software to rebuild or recover from partition/filesystem problems
• PhotoRec: Block-by-block recovery software for known file types
• GParted: graphical partition editor

In addition, there are several commercial disk-recovery applications available.

A note on backups: as I mentioned at the beginning of this post, my backup of the data on this disk was out of date.  As I tried to recover them, I realized just how important that data was.  To avoid the recurrence of this problem in the future, I implemented a backup strategy for irreplaceable data:

1. Master data stored on my machine’s internal drive
2. Frequent backups, using <code>rsync</code>, to a local external backup drive
3. Less frequent backups to an EBS volume in Amazon EC2-land (again using <code>rsync</code>)

A future move will be to switch to RAID1 or RAID5 storage locally, to be able to handle a hardware failure.