chitchcock/How I saved a year of our family pictures from a dead hard drive.

## How I saved a year of our family pictures from a dead hard drive.
Copied from http://arstechnica.com/civis/viewtopic.php?f=19&t=1197911 (via http://www.libertypages.com/clarktech/?p=349)
-----------------------------------------------

MarkLT1
Ars Scholae Palatinae
et Subscriptor
Tribus: Where the women are strong, the men are good looking, and all the children are above average.
Registered: Nov 11, 2002
Posts: 924
-----------------------------------------------
I thought this might be useful to the rest of the MacAch, in case anyone else ends up in a similar situation.

------ Back Story ------ (skip down to the next section for the data recovery portion)

So on Wednesday night, my wife's MBP hard drive suddenly died. Upon a reboot in verbose mode (as the machine wouldn't boot) I was getting the dreaded Bus I/O error when the drive was being accessed. I quickly shut the machine off in order to prevent further damage in case anything was salvageable.

My first thought was "No biggie- we have Time Machine!" So I go and look through the remote TM drive files, and realize that the last time my wife's machine was backed up, was roughly a year ago, around the time we installed Lion on it. Ugh. Tried to connect the MBP in FireWire mode to my Mac Pro- no go.

Thought 2- this is an old machine (2007 MBP), perhaps it is the SATA chip on board that is dying. So I got out the micro screw drivers, and T6 torx bit, and pulled the drive, to put it in an external FW case. Plugged it into my Mac Pro, and no go, the drive will not mount. Disk Utility is showing a greyed out "Macintosh HD" partition, that is formatted with HFS+, which was promising, but there was no way to access the files. I also noticed that in the console I was getting periodic lines of:

Code:
Mar 14 15:25:35 MacPro.local kernel[0]: disk3s2: I/O error.


This actually was important later.

----- How I recovered the data -----

It has been a long time since I had recovered data from a failing drive, but I did remember the number one rule- access the drive as little as possible, as if there is a physical issue (i.e.- the heads crashing onto the platter) every time the head moves, you might be damaging the drive more. If it is a logical problem, every time you write to the drive, you damage it more.

The first thing I did was fire up a terminal window, and at the suggestion of a friend, installed ddrescue via MacPorts:

Code:
sudo port install ddrescue


I next ran (with the drive still attached):

Code:
diskutil list


to see the disk identifier of the partition I wanted to save. This yielded the following:

Code:
/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *501.2 GB   disk3
   1:                        EFI                         209.7 MB   disk3s1
   2:                  Apple_HFS Macintosh HD            499.1 GB   disk3s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3


So I knew that the partition I wanted to save was disk3s2.

The next step was to make an image of the failing drive. This is where ddrescue came into play. I created a directory on a drive with more than 499.1GB of space, cd'd to that directory and executed the command:

Code:
sudo /opt/local/bin/ddrescue -v -n -c 4096 /dev/rdisk3s2 Rescue.dmg Rescue.log


This is launching ddrescue in verbose mode (-v), will skip the splitting failed blocks step (-n), sets the cluster size of sectors read to 4096, and copies the raw disk data from /dev/rdisk3s2 to a dmg named Rescue. It also outputs a log at Rescue.log (this is important- it allows you to interrupt the copy, and start up where you left off).

When this started, it was moving through the disk at about 23kb/sec, which by my calculation would take roughly 264 days to read the drive. Ugh. I noticed that the read was interrupted (drive sound wise) whenever the console would output that I/O error which was happening every second or so. I thought it might be that I had parallels running, so I quit parallels. Suddenly the speed burst up to 30MB/sec, but only for about 10 seconds. Then the I/O error started hitting every second or so again. I figured, it must be the finder pinging the drive, trying to mount it.

Some google searching lead me to a great tool which allows you to suppress the mounting of disks and images- Disk Arbitrator ( https://github.com/aburgh/Disk-Arbitrator ). I ran DA, and set mounting to off. Suddenly the ddrescue speed jumped up to 70MB/sec. So now, my estimated time was roughly 2 hours. Yay.

About 350gigs into the read, ddrescue started to run into problems on the drive. The first 350gigs took roughly an hour and 20 minutes. The last 150 gigs took about 3 hours to get through. Once the initial pass was complete, about 370MB of bad sectors were found on the drive. The next step ddrescue goes through is a reverse pass, where it re-reads the bad sectors, and trims out the still good data. This process took another 3-hours, and reduced the size of the errors on the image to about 200MB. The final pass (which i elected to skip, with my -n) further attempts to split out the errors, but it can be orders of magnitude more time, and yields a relatively small return usually.

Once it was complete, I disconnected the bad drive, turned on mounting in Disk Arbitrator (this step is important! I forgot to do it at first, and was getting very strange no-file-system errors when trying to mount the Rescue.dmg, and it took me a good hour to figure out what was going on), and attempted to mount the disk image. No go- the finder complained that the disk was damaged.

I happened to have a blank 1TB drive in this machine, so next, I did a reverse copy of the image, to the blank drive, again using ddrescue:

Code:
sudo /opt/local/bin/ddrescue --force -v -c 4096 Rescue.dmg /dev/rdisk0s2 recovery.log


where rdisk0s2 was the blank 1TB partition. This took a couple hours.

Once complete, I ran Disk Warrior, and attempted to repair the good drive, which contained all the data copied off the bad drive.

----- The Result -----

Well, there were two particular groups of data I was looking for-

1. my wife's iPhoto library and
2. my wife's Aperture library

These happened to contain most of the pictures of my 3-year-old son.

Both the iPhoto library, and Aperture library were pulled intact, as were all but a few old word docs in my Wife's user directory. Success!

----- The Moral of the story -----

I learned a couple of valuable lessons here.
Just because you have a backup system, doesn't mean it is running. Make sure your backups are actually being done.
Don't trust TM as your only backup. (it looks as if TM was switched off when I updated the machine to lion, and I was never notified of such)
With an 8-month pregnant wife, you will find a way, no matter how impossible, to restore your family pictures if they are lost (my backup plan was to re-enact all of our son's 2-3 year old shots). :)
	Copied from http://arstechnica.com/civis/viewtopic.php?f=19&t=1197911 (via http://www.libertypages.com/clarktech/?p=349)
	-----------------------------------------------

	MarkLT1
	Ars Scholae Palatinae
	et Subscriptor
	Tribus: Where the women are strong, the men are good looking, and all the children are above average.
	Registered: Nov 11, 2002
	Posts: 924
	-----------------------------------------------
	I thought this might be useful to the rest of the MacAch, in case anyone else ends up in a similar situation.

	------ Back Story ------ (skip down to the next section for the data recovery portion)

	So on Wednesday night, my wife's MBP hard drive suddenly died. Upon a reboot in verbose mode (as the machine wouldn't boot) I was getting the dreaded Bus I/O error when the drive was being accessed. I quickly shut the machine off in order to prevent further damage in case anything was salvageable.

	My first thought was "No biggie- we have Time Machine!" So I go and look through the remote TM drive files, and realize that the last time my wife's machine was backed up, was roughly a year ago, around the time we installed Lion on it. Ugh. Tried to connect the MBP in FireWire mode to my Mac Pro- no go.

	Thought 2- this is an old machine (2007 MBP), perhaps it is the SATA chip on board that is dying. So I got out the micro screw drivers, and T6 torx bit, and pulled the drive, to put it in an external FW case. Plugged it into my Mac Pro, and no go, the drive will not mount. Disk Utility is showing a greyed out "Macintosh HD" partition, that is formatted with HFS+, which was promising, but there was no way to access the files. I also noticed that in the console I was getting periodic lines of:

	Code:
	Mar 14 15:25:35 MacPro.local kernel[0]: disk3s2: I/O error.


	This actually was important later.

	----- How I recovered the data -----

	It has been a long time since I had recovered data from a failing drive, but I did remember the number one rule- access the drive as little as possible, as if there is a physical issue (i.e.- the heads crashing onto the platter) every time the head moves, you might be damaging the drive more. If it is a logical problem, every time you write to the drive, you damage it more.

	The first thing I did was fire up a terminal window, and at the suggestion of a friend, installed ddrescue via MacPorts:

	Code:
	sudo port install ddrescue


	I next ran (with the drive still attached):

	Code:
	diskutil list


	to see the disk identifier of the partition I wanted to save. This yielded the following:

	Code:
	/dev/disk3
	#: TYPE NAME SIZE IDENTIFIER
	0: GUID_partition_scheme *501.2 GB disk3
	1: EFI 209.7 MB disk3s1
	2: Apple_HFS Macintosh HD 499.1 GB disk3s2
	3: Apple_Boot Recovery HD 650.0 MB disk3s3


	So I knew that the partition I wanted to save was disk3s2.

	The next step was to make an image of the failing drive. This is where ddrescue came into play. I created a directory on a drive with more than 499.1GB of space, cd'd to that directory and executed the command:

	Code:
	sudo /opt/local/bin/ddrescue -v -n -c 4096 /dev/rdisk3s2 Rescue.dmg Rescue.log


	This is launching ddrescue in verbose mode (-v), will skip the splitting failed blocks step (-n), sets the cluster size of sectors read to 4096, and copies the raw disk data from /dev/rdisk3s2 to a dmg named Rescue. It also outputs a log at Rescue.log (this is important- it allows you to interrupt the copy, and start up where you left off).

	When this started, it was moving through the disk at about 23kb/sec, which by my calculation would take roughly 264 days to read the drive. Ugh. I noticed that the read was interrupted (drive sound wise) whenever the console would output that I/O error which was happening every second or so. I thought it might be that I had parallels running, so I quit parallels. Suddenly the speed burst up to 30MB/sec, but only for about 10 seconds. Then the I/O error started hitting every second or so again. I figured, it must be the finder pinging the drive, trying to mount it.

	Some google searching lead me to a great tool which allows you to suppress the mounting of disks and images- Disk Arbitrator ( https://github.com/aburgh/Disk-Arbitrator ). I ran DA, and set mounting to off. Suddenly the ddrescue speed jumped up to 70MB/sec. So now, my estimated time was roughly 2 hours. Yay.

	About 350gigs into the read, ddrescue started to run into problems on the drive. The first 350gigs took roughly an hour and 20 minutes. The last 150 gigs took about 3 hours to get through. Once the initial pass was complete, about 370MB of bad sectors were found on the drive. The next step ddrescue goes through is a reverse pass, where it re-reads the bad sectors, and trims out the still good data. This process took another 3-hours, and reduced the size of the errors on the image to about 200MB. The final pass (which i elected to skip, with my -n) further attempts to split out the errors, but it can be orders of magnitude more time, and yields a relatively small return usually.

	Once it was complete, I disconnected the bad drive, turned on mounting in Disk Arbitrator (this step is important! I forgot to do it at first, and was getting very strange no-file-system errors when trying to mount the Rescue.dmg, and it took me a good hour to figure out what was going on), and attempted to mount the disk image. No go- the finder complained that the disk was damaged.

	I happened to have a blank 1TB drive in this machine, so next, I did a reverse copy of the image, to the blank drive, again using ddrescue:

	Code:
	sudo /opt/local/bin/ddrescue --force -v -c 4096 Rescue.dmg /dev/rdisk0s2 recovery.log


	where rdisk0s2 was the blank 1TB partition. This took a couple hours.

	Once complete, I ran Disk Warrior, and attempted to repair the good drive, which contained all the data copied off the bad drive.

	----- The Result -----

	Well, there were two particular groups of data I was looking for-

	1. my wife's iPhoto library and
	2. my wife's Aperture library

	These happened to contain most of the pictures of my 3-year-old son.

	Both the iPhoto library, and Aperture library were pulled intact, as were all but a few old word docs in my Wife's user directory. Success!

	----- The Moral of the story -----

	I learned a couple of valuable lessons here.
	Just because you have a backup system, doesn't mean it is running. Make sure your backups are actually being done.
	Don't trust TM as your only backup. (it looks as if TM was switched off when I updated the machine to lion, and I was never notified of such)
	With an 8-month pregnant wife, you will find a way, no matter how impossible, to restore your family pictures if they are lost (my backup plan was to re-enact all of our son's 2-3 year old shots). :)