<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">This follows up a hard drive recovery problem I posted a month or so ago and finally started to work on. There is moderately high value data on the partition table damaged Seagate because my Dad prepared his taxes over Christmas. So I'd like to get this one right. Here's what I found and some questions for the Linux-savvy.<br><br>Screenshots over at Flickr<br>TestDisk Scans promising<br>DD backup I/O issues and Predicting backup time from test runs<br>Using DD OF=image file, versus cloning<br>Bad sector count error mssg in TestDisk confusing<br>Ubuntu Live and community library load failure<br><br><br>I couldn't find the TestDisk logfile, but here are screenshots taken with my camera where you can quickly grasp the details:<br><br>http://www.flickr.com/photos/60501213@N02/<br><br><br>With a deeper TestDisk scan, the drive partitions come out  just as I set
 them during the failed Partition Magic session that caused the drive to crash, and the data seem to be intact as well. It seems the only thing to do is to continue with the deeper scan and save the partitions as they are given in the scan results. (This over-writes the partition table... Correct?)<br><br>But I wanted to first back up the drive before changing anything and tried a couple flash drives as tests. A test run of an 8GB Flash card (probably class 4 at 4 mb/sec) took 2 hours to complete a DD image copy. I copied to a file because I am concerned about differing drive geometries going from a Seagate 3.5" to a portable Western Digital (inspired by comments on the web). A test run using  a 1GB Flash Drive (with a 0.5GB deleted partition) took only 30 seconds! But the test recovery of this took almost six minutes??? All 3 tests were done with a USB portable WD drive as the target, running at 5400 rpm.<br><br>Do you know where the i/o bottleneck
 is in this 1.1 mb/sec transfer?<br><br>At this rate the 200GB Seagate would take 50 hours to back up, and who knows how long to restore, should that be necessary. Hopefully the bottleneck is in the flash medium.<br><br><br>Does anyone know if the following sector count issue caused the drive crash (from Partition Magic)? (Why would Partition Magic mess with drive geometry values?)<br><br>TestDisk Errors:<br><br>"Bad sector count.<br>Warning: incorrect number of heads/cylinders 240 (FAT) != 255 (HD)<br>Warning: incorrect number of heads/cylinders 240 (NTFS) != 255 (HD)" etc. for each partition.<br><br>I'm not conversant in the != convention, (nothing came up in Google) and not sure if it's getting a false alarm or if it's re-setting the value to 255. Because later:<br><br>"Warning: The current number of heads per cylinder is 255 but the correct value may be 240. You can use the Geometry menu to change this value...."<br><br>As the drive is listed at
 Seagate as having 256 heads (presumably counting the 0-head as 1), and especially since the deep scan came out perfectly (I think) there doesn't seem to be anything to do about the geometry values. (Is this 255/256 discrepancy nothing to worry about?)<br><br>Seagate spec sheet:<br>http://www.seagate.com/ww/v/index.jsp?vgnextoid=bbec3b0c2aeef010VgnVCM100000f5ee0a0aRCRD&locale=en-US&reqPage=Legacy<br><br><br>Finally, I tried to load TestDisk in  the Synaptic Package Manager running Ubuntu Live, but it couldn't find any of the programs in the community library. Is this common? I used a Linux rescue ISO mashup that included TestDrive instead, which added a lot of load time switching between live CDs to run DD in Ubuntu and TestDisk from a systemrescue ISO.<br><br>Thanks in advance for sharing your experience and expertise.<br><br><br></td></tr></table><br>