note: This post is more for my own future reference than anything else, but I figure it might help others out in a jam, so i’d post it here — Paul.
Recently, I was asked to attempt to recover an NTFS based drive that had developed “Click Of Death” — in a laptop that moves around a bit, such a thing is not uncommon, but I always forget the lines that ddrescue that work ‘most reliably’ for me when i’m on a remote machine, so i’m documenting them for completeness.
Firstly, back up the MBR / Partition Table (really, really useful on NTFS based machines that fail)
dd if=/dev/sdX of=/media/working-drive/mbr.code bs=512 count=1
Then, presuming the destination drive is as, or is larger than the source one, run:
ddrescue --no-split /dev/sdX /media/working-drive/backup_cdrive.img /media/working-drive/backup_cdrive.log ddrescue --direct --preallocate --max-retries=9 /dev/sdX /media/working-drive/backup_cdrive.img /media/working-drive/backup_cdrive.log ddrescue --direct --preallocate --retrim --max-retries=9 /dev/sdX /media/working-drive/backup_cdrive.img /media/working-drive/backup_cdrive.log
Then, when you’ve checked your images for bugs with a tool like ‘testdisk’ or’sectrecover’ or any commerical based one you may have on hand, the recovery process is:
- Partition the new drive.
- Restore Images
- Run: dd if=/media/working-drive/mbr.code of=/dev/sdY bs=446 count=1
“Restore Images” in this case, can be:
- something physical, like: e2fsck -f /media/working-drive/backup_cdrive.img && dd if=/media/working-drive/backup_cdrive.img of=/dev/sdY[1-100]
- or, something virtual, like: e2fsck -f /media/working-drive/backup_cdrive.img && VBoxManage convertfromraw backup_cdrive.img backup_cdrive.vdi –format VDI
(and, for those wondering — the 446 byte copy is due to the fact the new drive is probably not the same as the old one, so we’ll do the partitioning manually and only recover the MBR code, not the whole lot — which is a 446 byte MBR, a 64 byte partition table and a 2 byte signature block.)