We would like to describe the almost totally successful recovery of a system using two things, which we had previously been a bit sceptical about. The first was that of putting a hard drive in the freezer and the second was the use of the dd_rescue linux utililty on what was by then known to be a damaged hard drive.
We also describe, in an Addendum, how to use dd_rescue to simply clone one whole drive to another one.
Windows 2000 Professional; Seagate 10GB IDE; 512MB DDR; Asrock K8NF4G-SATA2; Sempron 3000.
System slow down and with some applications not functioning (eg Nero wouldn't burn disks). Slow or incomplete POST with the HDD sometimes being detected in the BIOS setup and sometimes not. BIOS messages such as F2 to Enter Setup or otherwise Continue would be followed by a freeze of the system. When the BIOS could be entered the size of the HDD was incorrectly identified as 5GB. Problems were intermittent and could happen on both cold and warm boots. The owners particularly wanted some pictures (2GB) to be made safe.
Once an external USB IDE HDD had been attached to copy the files to and after about 20 attempts the system just refused to boot-up any more (with or without the USB drive attached) and the HDD was not detected in the BIOS setup during this time. There were also audible noises and clunks from the HDD. A Knoppix Live CD would start to load with the normal display but then freeze. All of these actions were like watching things in slow motion.
Headed for bed but thought there was nothing to lose by putting the HDD into a ziplock plastic bag into the freezer. In the morning the HDD was reattached and the Knoppix CD (still in its drawer) just booted straight up in sprightly fashion after having whizzed through the POST screens. Both internal and external HDDs were identified as HDA and SDA respectively on the Knoppix Desktop. Both had two partitions on them.
- One partition on the 200GB external was reformatted as NTFS using GParted to be capable of holding a file bigger than 4GB.
- This partition showed on the desktop as SDA5 (first logical partition) and was opened (and thus mounted) to show the green triangle in one corner.
- The SDA5 icon was right-clicked and the read/write mode made writable.
- A root shell console was opened from the K-button's KNOPPIX menu item.
- Just the very most basic dd_rescue command was next issued to copy the system partition from the IDE drive to the USB drive (and with no other options so that only the defaults would be processed): viz:-
# dd_rescue /dev/hda1 /media/sda5/cloone.img
- Unlike dd the dd_rescue program doesnt stop if errors are encountered. It just slows down as errors are encountered and nulls are substituted. It also has the huge benefit that one can watch its progress.
- It took between 2 and 3 hours to copy the 5+ GB partition and the final output is shown in Fig. 1.
- Fig 1
- For those that want to read the dd_rescue options now they are listed at DDRESCUE. They can also be listed at the console's command prompt by just entering dd_rescue on its own.
- The MBR was backed-up using dd instead of dd_rescue. Note the different syntax using if= and of= and so on. We weren't sure how to just copy one single sector with dd_rescue and, in an acute situation, thus reverted to the familiarity of using dd: viz:-
# dd if=/dev/hda of=/media/sda5/mbr.dat bs=512 count=1
- The system actually booted-up normally before freezing again and then couldn't be rebooted. The drive was returned to the fridge for a few hours and then the system booted normally into Windows once again!
- Newly discovered by us (and potentially very useful in a number of ways) the HDD utility HD Tune 2.53 was downloaded and run. The scan of its results are shown in Fig. 2.
- Fig 2
- It is clear that the utility found errors and these were not abolished by running chkdsk /r from the command prompt and rebooting. It was clear to us that the drive needed to be scrapped so we moved to recover the image file to another hard drive rather than mess around writing zeros to the drive, etc, etc.
- A 20 GB Maxtor IDE drive was substituted for the 10 GB Seagate and the system rebooted to Knoppix where we used dd to first put back the copy of the MBR: viz:-
# dd if=/media/sda5/mbr.dat of=/dev/hda
- Next the 5+ GB image file was restituted using dd: viz:-
# dd if=/media/sda5/cloone.img of=/dev/hda1
- The PC was rebooted and went quickly into the newly restored partition. Nero wouldn't work till it was uninstalled and reinstalled. All the most important data was copied to CDRs. Some picture files (and no doubt other files) just could't be copied - presumably because of the underlying damaged sectors.
- We are awaiting delivery of a brand new SATA hard drive and rather than restore the apparently still functional Win2K OS think it wise to do a brand new clean reinstallation once it arrives
Well - a very satisfactory and pleasing result. It really wasn't at all hard to do. We were very surprised that the "freezer trick" worked, since it has been a dismal failure in the past. We were absolutely delighted with dd_rescue and can see we will be using it in place of dd in the future as we grow in familiarity with it.
728 errors were found on the drive and it is apparently these that incredibly slow up such sector by sector copying and if the drive is getting unstable the warmer it gets then obviously time is of the essence.
We will use it in preference in particular because it tells you what progress it is making - one of the major faults with using dd. And Knoppix really is a "life-saver" - once again.
Addendum - Simply cloning a whole drive.
We have described above exactly how we used dd_rescue for the first time. We possibly made it more complicated than needs be by doing it in stages. That is by copying the contents of the only partition (hda1 in that example) to an image file and backing-up the MBR to another file. We then restored both of these files to a new hard drive. There can be advantages in creating a clone (of a partition or of a whole drive) as an image file, and indeed of knowing how to make a backup of the MBR, but in fact we could have done everything much more simply by just directly cloning drive-to-drive. As long as Knoppix can see the drives, be they internal or external floppy/hard drives (made of spinning magnetic or of solid-state flash memory media) then direct cloning should be both possible and likely to succeed. (As long as the output device is as large or larger than the input then the copying continues till the end of the input device is reached. If the output device is too small copying will continue till the the end of the output device is reached so only a partially complete clone would be created).
We thus now describe how we cloned a 32MB flash memory drive to another 32MB drive
using dd_rescue. The two drives became /dev/sdb and /dev/sdf in Knoppix 5.1.1. The root shell
was opened from "K-Start Menu ... Knoppix ... Root Shell". The simple command ...
dd_rescue /dev/sdb /dev/sdf
... was entered at the "root@Knoppix:~#" prompt. The whole process was quick (only 32 MB of course) and the output is seen in the screenshot shown below. NB: all original data on the second drive, sdf, was of course completely overwritten. Always be absolutely clear that the second device, the outfile, has been correctly identified before hitting the Enter key.
The second to fourth lines "dd_rescue: (info): ipos:" through to "avg.load: 0.3%" keep updating during the procedure and allow one to follow the progress. If bad blocks are encountered during cloning then additional error lines are displayed (as in the bad drive recovery outlined earlier) though in this example, and since both were good drives, no errors were detected. When completed the EOF line and Summary are displayed before returning to the "root@Knoppix:~#" prompt. It thus differs from using native dd not only because the progress can be followed but also because the infile and outfile device IDs are written simply as the respective devices, in that order and without the preceeding if= and of= prefixes as used by native Linux dd. If things seem a bit hard to comprehend perhaps read a few of the tips on our Back-up using Knoppix page.