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:
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.
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!
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:
- Master data stored on my machine’s internal drive
- Frequent backups, using <code>rsync</code>, to a local external backup drive
- 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.