Recover files from NTFS disk image?
December 28, 2008 4:37 PM Subscribe
A relative's Windows XP (NTFS) machine was accidentally reinstalled from a recovery partition. We need to recover as much as possible from this reformatted disk.
I bought a new external hard drive, booted into Knoppix and created a disk image file using "dd if=/dev/sda of=/mount/newexternal/disk.image" ... which is to say that the entire physical disk is stored as a file on the new disk.
1) What are some good tools I can use (best would be from within OS X, second best from Knoppix) to try and recover files from that image?
2) How can I get those tools to read from that image? Will there be issues mounting it via loopback since it's an image of an entire physical disk, not of a partition? How can I get around that?
I bought a new external hard drive, booted into Knoppix and created a disk image file using "dd if=/dev/sda of=/mount/newexternal/disk.image" ... which is to say that the entire physical disk is stored as a file on the new disk.
1) What are some good tools I can use (best would be from within OS X, second best from Knoppix) to try and recover files from that image?
2) How can I get those tools to read from that image? Will there be issues mounting it via loopback since it's an image of an entire physical disk, not of a partition? How can I get around that?
Hey, dmd!
The biggest question here is how the reinstallation happened. If I recollect, XP will reinstall to an NTFS partition and either do a "Quick Format," or do it the long and hard way.
The long and hard way makes things much more difficult to recover. The Quick Format just seems to start putting stuff on that partition immediately.
Find out which happened, possibly by stepping said relative through the installation process and finding out which one they picked. What they did will determine just how hard your job will be. Sorry not to have something more useful to tell you.
posted by adipocere at 5:38 PM on December 28, 2008
The biggest question here is how the reinstallation happened. If I recollect, XP will reinstall to an NTFS partition and either do a "Quick Format," or do it the long and hard way.
The long and hard way makes things much more difficult to recover. The Quick Format just seems to start putting stuff on that partition immediately.
Find out which happened, possibly by stepping said relative through the installation process and finding out which one they picked. What they did will determine just how hard your job will be. Sorry not to have something more useful to tell you.
posted by adipocere at 5:38 PM on December 28, 2008
Response by poster: I'm almost certain it was a quick format, as the process of the reinstall from the "HP recovery partition" only took about 10 minutes. If it was a full format (of the 250GB disk) it would have taken much, much longer!
posted by dmd at 5:45 PM on December 28, 2008
posted by dmd at 5:45 PM on December 28, 2008
It's going to be easiest if you recover from a boot CD, rather than in Windows. My suggestion would be to download/burn the Ultimate Boot CD for Windows and use the recovery tools there.
posted by Kickstart70 at 8:51 PM on December 28, 2008
posted by Kickstart70 at 8:51 PM on December 28, 2008
Best answer: A quick squizz at the MountImage Pro software that procrastination linked to looks like it will do what you want. It talks about mapping drive letters to "any or all partitions within the image files", so it will probably cope just fine with a dd of the whole disk.
If you put that dd image on a Linux ext3 filesystem, though, you'll need to install something like Ext2 IFS for Windows to let MountImage Pro see the image file.
In fact it's probably going to be easier to run your recovery tools against the actual reformatted disk, rather than against its image; just keep the image as a backup, letting you restore the disk to the state it was in before the recovery tool touched it in case a recovery tool screws it up for you or you want to try several tools.
By the way, dd will run much faster if you include bs=1M in its parameter list, since that makes it do its reads and writes in megabyte-sized blocks (the default read and write block sizes are 512 bytes). It will correctly handle the partial block at the end of the copy if the file being copied is not an exact multiple of 1 megabyte long.
I'm not aware of Linux-based NTFS file recovery software, so gaining access to the partitions inside your image file from Linux probably won't help you much in this case. Knowing how to do that is useful for getting at intact filesystems in whole-disk images, though, so here's the recipe.
You need to use the losetup command's --offset (-o) option. This expects an offset in bytes. Hard disks with partition tables generally use 512-byte sectors, so to get the correct offset into a hard disk image file, you need to multiply the appropriate partition's starting block number by 512 to get the required byte offset.
Here's an Ubuntu example to get you going. Just about any Linux distro will work essentially the same way, though you might need to use some mechanism other than sudo to get the required root privileges.
I've found a folder called /home/stephen/backups that contains files sdb and sdb.ddrescue.log, so I'm pretty sure that sdb is a disk image. It's 512MB big, so it's probably an image of one of my USB sticks. That will do.
posted by flabdablet at 3:34 AM on December 29, 2008
If you put that dd image on a Linux ext3 filesystem, though, you'll need to install something like Ext2 IFS for Windows to let MountImage Pro see the image file.
In fact it's probably going to be easier to run your recovery tools against the actual reformatted disk, rather than against its image; just keep the image as a backup, letting you restore the disk to the state it was in before the recovery tool touched it in case a recovery tool screws it up for you or you want to try several tools.
By the way, dd will run much faster if you include bs=1M in its parameter list, since that makes it do its reads and writes in megabyte-sized blocks (the default read and write block sizes are 512 bytes). It will correctly handle the partial block at the end of the copy if the file being copied is not an exact multiple of 1 megabyte long.
I'm not aware of Linux-based NTFS file recovery software, so gaining access to the partitions inside your image file from Linux probably won't help you much in this case. Knowing how to do that is useful for getting at intact filesystems in whole-disk images, though, so here's the recipe.
You need to use the losetup command's --offset (-o) option. This expects an offset in bytes. Hard disks with partition tables generally use 512-byte sectors, so to get the correct offset into a hard disk image file, you need to multiply the appropriate partition's starting block number by 512 to get the required byte offset.
Here's an Ubuntu example to get you going. Just about any Linux distro will work essentially the same way, though you might need to use some mechanism other than sudo to get the required root privileges.
I've found a folder called /home/stephen/backups that contains files sdb and sdb.ddrescue.log, so I'm pretty sure that sdb is a disk image. It's 512MB big, so it's probably an image of one of my USB sticks. That will do.
stephen@jellyfish:~/backups$ ls -ltotal 499892-rw-r--r-- 1 root root 511385600 2007-07-27 14:18 sdb-rw-r--r-- 1 root root 111 2007-07-27 14:18 sdb.ddrescue.logstephen@jellyfish:~/backups$First thing is to read the image's partition table:
stephen@jellyfish:~/backups$ sfdisk --dump sdb# partition table of sdbunit: sectors sdb1 : start= 32, size= 998464, Id= 6 sdb2 : start= 0, size= 0, Id= 0 sdb3 : start= 0, size= 0, Id= 0 sdb4 : start= 0, size= 0, Id= 0stephen@jellyfish:~/backups$Looks like the first partition is the only one with anything in it, so set up a loop device with an appropriate offset to get to that partition:
stephen@jellyfish:~/backups$ sudo losetup -f/dev/loop0stephen@jellyfish:~/backups$ sudo losetup -o $((32*512)) /dev/loop0 sdbstephen@jellyfish:~/backups$Now I can mount the partition:
stephen@jellyfish:~/backups$ sudo mount /dev/loop0 /mntstephen@jellyfish:~/backups$ ls -l /mnttotal 17928drwxr-xr-x 2 root root 8192 2007-07-02 15:03 101msdcf-rwxr-xr-x 1 root root 163840 2006-11-28 17:42 BB&A Fest Volunteers info and registration Jan 05.docdrwxr-xr-x 2 root root 8192 2007-07-01 14:32 bruthen-floods-2007-rwxr-xr-x 1 root root 17862238 2007-07-17 16:32 Firefox 2.0.0.4.dmgdrwxr-xr-x 4 root root 8192 2007-03-15 15:15 ServicePacksdrwxr-xr-x 2 root root 8192 2007-03-14 12:44 SysFILES-rwxr-xr-x 1 root root 90858 2007-03-14 15:42 vel002.xml-rwxr-xr-x 1 root root 191636 2007-07-19 16:15 VF_RFT_OU6220707_Thinning-with-scribbles.pdfstephen@jellyfish:~/backups$Note in particular that mounting /dev/loop0 as /mnt does not require -o loop. Passing the loop option to mount makes it do a losetup behind the scenes. We're doing the losetup explicitly, so we don't want mount to do it for us. That also means we need to remember to do
sudo losetup -d /dev/loop0 after umounting /mnt, since umount won't automatically tear down a losetup that mount didn't do.posted by flabdablet at 3:34 AM on December 29, 2008
Here are a couple of handy bash scripts for mounting and unmounting all the partitions inside a whole-disk image file.
posted by flabdablet at 5:18 AM on December 30, 2008
posted by flabdablet at 5:18 AM on December 30, 2008
This thread is closed to new comments.
mount -o loop ntfsimage.dd /ntfs
At the very worst, you could get a working drive and just restore the image back on a drive to work from.
At that point, depending on what exactly happened to the disk, you will need something to recover the files. In all likelihood, the file names and metadata are gone, as I would bet that the resinstall killed the MFT and backup MFT. But if there was no low level reformat, then the data might be there. I use PhotoRec for this type of recovery. This will produce tons of files with numeric names that you will have to check for usefulness.
Good luck. This is quite a painful chore. Please update what you find.
posted by procrastination at 4:57 PM on December 28, 2008