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
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,
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
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!
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.
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
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.
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!
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!
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.
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 -
Mark Rogers -
Steve Engledow -
steve-ALUG＠hst.me.uk -
Thomas Pircher