Recovering data from a disk image
I have a disk image taken around ten years ago. It has a .dsk file extension, which might be a clue to what I used to take the image but more likely is something I picked because it was a disk! I'm trying to recover data from it but none of my normal tools are recognising it. Eg: $ file myfile.dsk myfile.dks: data $ fdisk -l myfile.dsk Disk myfile.dsk: 39.7 GB, 39711651840 bytes 255 heads, 63 sectors/track, 4828 cylinders, total 77561820 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk myfile.dsk doesn't contain a valid partition table Testdisk isn't giving me any clear results (it can find an ext3 partition but doesn't seem then able to extract anything from it). I'm pretty sure this was a straight image from a physical disk (it could have been a virtual disk but it's 39GB so I doubt that). It's quite possible that the default geometry settings in tesdisk etc are wrong but short of random guesses I don't know what to try. I am confident my data is there; if I view the raw data I am able to find a lot of it (mostly scripts which are therefore in plain text). Not that this is a very easy way to extract data! Suggestions as to what I should do to recover data? If it helps, the first 4096 bytes are all zero (so there's no obvious file header). Mark -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On 02 Mar 17:05, Mark Rogers wrote:
I have a disk image taken around ten years ago. It has a .dsk file extension, which might be a clue to what I used to take the image but more likely is something I picked because it was a disk!
I'm trying to recover data from it but none of my normal tools are recognising it. Eg: $ file myfile.dsk myfile.dks: data $ fdisk -l myfile.dsk Disk myfile.dsk: 39.7 GB, 39711651840 bytes 255 heads, 63 sectors/track, 4828 cylinders, total 77561820 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk myfile.dsk doesn't contain a valid partition table
Testdisk isn't giving me any clear results (it can find an ext3 partition but doesn't seem then able to extract anything from it).
OK - so maybe it doesn't know the correct partition type, try using kpartx on it and see if it can get some partitions that way? (despite it's name, kpartx is nothing to do with KDE, and is a very useful tool). Thanks, -- Brett Parker
On 2 March 2015 at 17:25, Brett Parker <iDunno@sommitrealweird.co.uk> wrote:
OK - so maybe it doesn't know the correct partition type, try using kpartx on it and see if it can get some partitions that way?
$ kpartx -av mydisk.dsk .. returns nothing, which by my understanding means it found nothing (I've not used kpartx before today though). Is there a simple way to get tools like "file" to look at an offset within the file? Eg it would be useful in this case to skip the leading blanks and see what follows. Mark -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On 02/03/15 17:05, Mark Rogers wrote:
I have a disk image taken around ten years ago. It has a .dsk file extension, which might be a clue to what I used to take the image but more likely is something I picked because it was a disk!
I'm trying to recover data from it but none of my normal tools are recognising it. Eg: $ file myfile.dsk myfile.dks: data $ fdisk -l myfile.dsk Disk myfile.dsk: 39.7 GB, 39711651840 bytes 255 heads, 63 sectors/track, 4828 cylinders, total 77561820 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk myfile.dsk doesn't contain a valid partition table
Testdisk isn't giving me any clear results (it can find an ext3 partition but doesn't seem then able to extract anything from it).
I'm pretty sure this was a straight image from a physical disk (it could have been a virtual disk but it's 39GB so I doubt that). It's quite possible that the default geometry settings in tesdisk etc are wrong but short of random guesses I don't know what to try.
I am confident my data is there; if I view the raw data I am able to find a lot of it (mostly scripts which are therefore in plain text). Not that this is a very easy way to extract data!
Suggestions as to what I should do to recover data?
If it helps, the first 4096 bytes are all zero (so there's no obvious file header).
Mark
Looking at the .dsk file extension, there are several Windows and Mac programs that use them. This http://www.file-extensions.org/dsk-file-extension-vmware-virtual-disk-file says "The DSK file extension was used by earlier versions of VMware products files that contain saved virtual disks. The latest versions of VMware are using the VMDK file extension instead." Were you using VMWare back then then? If so, see if you can mount it or update it to the latest version then mount it. Steve
On 2 March 2015 at 23:13, <steve-ALUG@hst.me.uk> wrote:
Were you using VMWare back then then? If so, see if you can mount it or update it to the latest version then mount it.
We were using VMWare in the past (as to whether we were back then I have no idea). 40GB seems a lot for a virtual disk but it's a definite possibility. Thanks for the tip, I'll see whether that gets me in! -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On 3 March 2015 at 10:10, Mark Rogers <mark@more-solutions.co.uk> wrote:
Thanks for the tip, I'll see whether that gets me in!
Sadly this got me nowhere so far, but I am not convinced this isn't the right track. I've tried (and failed) to find a way to determine whether this is indeed a VMWare .dsk file. VirtualBox won't allow me to use it as is (unsupported file). I was able to use "vboxmanage convertfromraw" to "convert" to a vdi file, but the resulting file wasn't valid and I'm pretty sure that treating the .dsk as a raw file is no different from trying to mount it directly in Linux. Some references I have found suggest that .dsk is indeed just a raw disk image (in which case I am no further forward!). It is possible that the image is corrupt (eg it might have been taken from a damaged disk); if so I need to find ways to try to repair the filesystem as much as is possible (I need very little off the old disk). What steps would I take to try to locate an ext* filesystem and repair it? It's reasonable to assume that it would have been a fairly typical Linux installation as I didn't know enough back then to have done much else. I think I was using Red Hat back then and a quick grep of the image suggests it was RH7. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On 03/03/15 11:03, Mark Rogers wrote:
On 3 March 2015 at 10:10, Mark Rogers <mark@more-solutions.co.uk> wrote:
Thanks for the tip, I'll see whether that gets me in! Sadly this got me nowhere so far, but I am not convinced this isn't the right track.
I've tried (and failed) to find a way to determine whether this is indeed a VMWare .dsk file. VirtualBox won't allow me to use it as is (unsupported file). I was able to use "vboxmanage convertfromraw" to "convert" to a vdi file, but the resulting file wasn't valid and I'm pretty sure that treating the .dsk as a raw file is no different from trying to mount it directly in Linux.
Some references I have found suggest that .dsk is indeed just a raw disk image (in which case I am no further forward!).
It is possible that the image is corrupt (eg it might have been taken from a damaged disk); if so I need to find ways to try to repair the filesystem as much as is possible (I need very little off the old disk). What steps would I take to try to locate an ext* filesystem and repair it? It's reasonable to assume that it would have been a fairly typical Linux installation as I didn't know enough back then to have done much else. I think I was using Red Hat back then and a quick grep of the image suggests it was RH7.
Just clutching at straws here, but could you DD it onto an empty Hard disk, then see if any disk tools can "fix" the disk and consequently recover the data? I suppose a pertinant question would be, what do you actually want from this file anyway? Because, if you just need some JPGs for instance, there are JPG recovery tools. My point is there may be specific tools for specific files. Steve
On 2015-03-03 12:03 pm, Mark Rogers wrote:
I've tried (and failed) to find a way to determine whether this is indeed a VMWare .dsk file.
You may try "qemu-img info FILE". With a bit of luck you might get some more information about the format of the file, if it is indeed a VM format. If the file format is recognised, you can then "qemu-img convert" it to another format, or just start it with qemu/kvm. Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-03-03 12:03 pm, Mark Rogers wrote:
I've tried (and failed) to find a way to determine whether this is indeed a VMWare .dsk file.
You've probably tried this already but if not, you could try running `strings` on the file to see if it produces anything recognisable that might give you a clue as to what's on it. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU9Z/3AAoJEL/3HArzwYbRWWwP/i7sMTDfzEYrVHKihawq73UZ GsXwmtsdMltG2BVnGlIJssML7s/xBTGEd0iEzL47WeNNFmR0iYQ4V3XVbctSXqAc lycNco4TuCYlvz6jQpv88RZXA2VOlvMSdVRmL54K2/o1Hm77fpQXAf9jDezzRBCi uXwquSo6dP/lZJTe+ferURN3yNwTlN7o4nXB8KOpHdE/ZiKq6ci5BJ9g/eJ5UM02 G7IK2W1C15bseNsslm6BjRtc+KU5QqWYzcwhASOfambDVZdPi86u+oZnMhgJEDy/ wws2hWCA0PqZXAlkNVjQnsq+0YJc9xyp8ilRWJyN8iyEggpNGC9AeL4OaSUJIIFT oppq7aLFC+v9KTuZFlS58Rndc244e8qUG4WFYaPJbrKoPi9WH6zGphyHZSICK6Lz YwtpI2DbkMWSI7r7mfS7DtsedsEiTnQjaEKRTnGDKTgq7hQ98JEbnoyWsNmi5kXn 9K1ndW6CB8Mk9dnqyaTfSEdo8Y7XP2VhFPX2v0ppVtLlt9BOKZHv+WcWRFBZ2XIF ikVYKLpo/OWsSuXgHgYq74UaOH0XFgeUOpiEaTW1yZoZMe3itVcmy3rO5qUx6Ob3 EaFukbDv5uxTtUgUL1EN9CSZ5LcTWi3QMyXtOKtwEVZhks8Bvf/2XBWPaa8TbDTA VG7RTxUhBhskjbVtooiK =YVig -----END PGP SIGNATURE-----
On 3 March 2015 at 11:17, Thomas Pircher <tehpeh-alug@tty1.net> wrote:
You may try "qemu-img info FILE". With a bit of luck you might get some more information about the format of the file, if it is indeed a VM format.
Thanks, that's the sort of command I needed. Unfortunately it just says "file format: raw", which I take to be another way of saying it's not a recognisable format. My current best guess is that I have a disk image from a real disk with chunks missing, including the first 4096 bytes which have all been zeroed. The data that is there is probably good, however. Given that the first 4096 bytes probably included all sorts of useful meta data about the rest of the disk this could be a problem but how best to proceed? To Steve: What I'm looking to recover is the "source" of an old website, so PHP/HTML (aka text) files, a few images, etc, and a MySQL database. I considered seeing what (eg) photorec or scalpel would give me, but under the circumstances it'll be more noise than signal. Plus: It's a challenge, and I'd like to find a way. The files aren't all that critical (I'm trying to recover them as a favour to someone), but I find it's times like this that I learn lots about filesystem recovery that turns out to be useful later on. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
I *might* be making some progress, or on the other hand... Using testdisk I scanned for partitions and found, allegedly, one at C/H/S = 3/112/46. Testdisk wouldn't add it for me because my disk image is too small - it looks like makybe I have only the first 40GB of a 400GB disk, although that should still include the data I'm looking for. So I added it manually and now: $ fdisk -l mydisk.dsk Disk mydisk.dsk: 39.7 GB, 39711651840 bytes 255 heads, 63 sectors/track, 4828 cylinders, total 77561820 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System mydisk.dsk1 53248 77561819 38754286 5 Extended mydisk.dsk5 55296 77561819 38753262 83 Linux So, taking the 55296 from fdisk [1]: $ sudo losetup /dev/loop0 mydisk.dsk -o $((55296 * 512)) $ sudo file -s /dev/loop0 /dev/loop0: Linux rev 1.0 ext3 filesystem data, UUID=a8a4611e-43c8-11d5-93cc-d0a0e5109e59 (errors) Looks like I now have a visible filesystem, albeit with errors. I then tried: $ sudo dumpe2fs /dev/loop0 dumpe2fs 1.42.9 (4-Feb-2014) Filesystem volume name: / Last mounted on: <not available> Filesystem UUID: a8a4611e-43c8-11d5-93cc-d0a0e5109e59 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal filetype sparse_super Default mount options: (none) Filesystem state: clean with errors Errors behavior: Continue Filesystem OS type: Linux Inode count: 4849664 Block count: 9695227 Reserved block count: 484761 Free blocks: 7452549 Free inodes: 4675796 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Last mount time: Fri Dec 6 16:24:24 2002 Last write time: Thu Apr 3 16:31:39 2003 Mount count: 10 Maximum mount count: -1 Last checked: Tue May 8 16:41:57 2001 Check interval: 0 (<none>) Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 First orphan inode: 213013 dumpe2fs: A block group is missing an inode table while reading journal inode The data presented in terms of mount/write times sounds like it could be about right, which is nice. So, what next? The help I found online suggested I used a backup superblock to recover the filesystem but there are none listed here (is that an ext2 vs ext3 thing?) I tried e2fsck: $ sudo e2fsck /dev/loop0 e2fsck 1.42.9 (4-Feb-2014) ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap e2fsck: Group descriptors look bad... trying backup blocks... e2fsck: Bad magic number in super-block while using the backup blockse2fsck: going back to original superblock e2fsck: A block group is missing an inode table while checking ext3 journal for / /: ********** WARNING: Filesystem still has errors ********** Like any of that means anything to me! [1] If someone can advise me how the 55296 relates to the C/H/S figures I'd love to understand that! -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On 3 March 2015 at 12:52, Mark Rogers <mark@more-solutions.co.uk> wrote:
I *might* be making some progress, or on the other hand...
OK, it looks like I might have ALUG stumped now? :-) Thanks for all the suggestions that got me this far. Looking at the data from dumpe2fs the file system was older than expected, or more to the point older than the files I was hoping to recover, and that lead me in other directions and I found the files elsewhere[1]. However, I feel like I'm on the verge of learning something useful here so for academic reasons only I'd like to continue seeing what I can can achieve here. In particular, I'd like to understand the relationship between the C/H/S values that testdisk gave me for the start and end of the ext2 partition (start: 3/112/46), and the start/end values that fdisk subsequently gave me for the same partition (start: 55296)? Does anyone have any pointers to good reading on this subject? The Internet is vast and on this subject the problem seems to be finding a good primer amongst the massive amount of information on the subject. [1] Lateral thinking: The files had been uploaded to a server, long since decommssioned. The backup of that server had also been deleted long ago, but a backup of the backup had survived on a different server. Turns out that it's surprisingly hard to actually get rid of data completely! -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On 04/03/15 11:38, Mark Rogers wrote:
In particular, I'd like to understand the relationship between the C/H/S values that testdisk gave me for the start and end of the ext2 partition (start: 3/112/46), and the start/end values that fdisk subsequently gave me for the same partition (start: 55296)?
Does anyone have any pointers to good reading on this subject? The Internet is vast and on this subject the problem seems to be finding a good primer amongst the massive amount of information on the subject.
Good? Not really. A start? Perhaps: https://en.wikipedia.org/wiki/Cylinder-head-sector Steve
On 4 March 2015 at 20:19, <steve-ALUG@hst.me.uk> wrote:
On 04/03/15 11:38, Mark Rogers wrote:
In particular, I'd like to understand the relationship between the C/H/S values that testdisk gave me for the start and end of the ext2 partition (start: 3/112/46), and the start/end values that fdisk subsequently gave me for the same partition (start: 55296)?
Good? Not really. A start? Perhaps: https://en.wikipedia.org/wiki/Cylinder-head-sector
Thanks! It took some experimenting but I finally got there: LBA Address A = (c ⋅ Nheads + h) ⋅ Nsectors + (s − 1) In my case c/h/s are 3/112/46 as above, and some playing around got me Nheads=255, Nsectors=63, ie: (3 * 255 + 112) * 63 + (46-1) = 55296 At least that means that I can avoid writing partition tables to my image now; I can calculate the value to throw at "sudo losetup /dev/loop0 mydisk.dsk -o <value>" without the extra step. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On 03 Mar 12:05, Mark Rogers wrote:
Plus: It's a challenge, and I'd like to find a way. The files aren't all that critical (I'm trying to recover them as a favour to someone), but I find it's times like this that I learn lots about filesystem recovery that turns out to be useful later on.
Are you sure it's a full disk image and not a single partition? You could try the "guess the filesystem" game and try: mount -o loop,ro -t ext2 image.dsk /mnt/thing (assuming that it was a linux boxen that it was from). Cheers, -- Brett Parker
participants (5)
-
Brett Parker -
Mark Rogers -
Steve Engledow -
steve-ALUG＠hst.me.uk -
Thomas Pircher