3

I wanted to make a bootable USB stick from a Knoppix.iso on GNU/Linux with dd.

Situation:

  1. Laptop with Linux Mint on it
  2. HDD mounted to system (.iso file on it) 1TB HDD (800 GB used)
  3. USB stick mounted on system (to make bootable)
  4. command used: $ sudo dd if=/HDD/knoppix.iso of=/dev/sdb

What happened:
I accidently typed in the wrong path into the command. Instead of writing to the USB I copied the knoppix.iso onto the HDD. As I noticed this, I immediately stopped the process. I reviewed the file structure of the HDD and everything was at its place, so I unmounted the HDD.
At home I attached the HDD to my PC with Win7 Professional. I found out that my data was gone and the unpacked knoppix.iso on the HDD. Since then I didn't attach the HDD to any kind of computer any more.

I tried to find a solution to resolve this problem, but I want to be sure to not mess something up since I have no experience here. I also didn't make a backup.

What I want to do:
I found PhotoRec and I want to try recovering my data with it.

Question:
Does this program help me reaching my goal here? And do you have recommendations on how to use it? Do you know any other programs which could be helpful here?

Nepumuk
  • 687
  • 1
    I disagree with that close vote. The suggested duplicate target question is about recovering a single file from an intact partition and file system; this question is about recovering a partition and possibly file system metadata as well as user data. (Note, it may still be a duplicate of some other question, but not that one.) – user Nov 06 '14 at 10:05
  • @MichaelKjörling I agree, the approach for recovering a wiped file and wiped partition table are different. – Anthon Nov 06 '14 at 10:53

1 Answers1

1

The good news is that the knoppix iso is relatively small compared to your drive size so even with the 1-2 minutes (an eternity in computer terms) only about 1% of your drive is overwritten, and most of your data is not wiped. If it were wiped, then even trying recovery would be almost impossible without huge cost.

Before unmounting the HDD, the system still had the original disk partition information in memory, as well as the filestructure. Since you did not go through the normal filesystem driver code, it had not noticed the underlying disc blocks had changed, and everything looked ok (but wasn't).

If you had not yet, you could have written down the output of fdisk -l, because that is a good way to start trying to restore the partitioning information. Once that is there you might have a chance to restore the filesystem(s) and try to use any redundant information (depending on the filesystem) to restore things.

Since you indicate connecting the drive to a Windows 7 machine, you probably had a VFAT or NTFS on the drive, which AFAIK have less recovery information than some of the Linux native filesystems.

PhotoRec will try to find files by combining elements of files that fit together. Depending on the fragmentation of the file, that can be a lenghty process, so trying to recover the partitioning and then the filesystem should have priority.

The first thing to do (if you don't alreayd have done that) is buy a 2 TB drive and make a copy of the 1Tb drive on there, so you can restore the 1TB drive restore to its current state when necessary (a new drive might be an investment but it will give you a backup device, irrespective of whether you get your data back).

Then try to restore the partition information. If you still know how you partitioned it, you can just try to do the same commands, no formatting of new partitions at any time!. Don't do so before you have made a backup copy of the whole drive!
If there were multiple partitions on the drive, then there is a good chance that all but the first can be complete recovered, once the partition information is restored.

Then try to recover the filesystem (tools depend on the type), if it is VFAT or NTFS, it might be that you better look for Windows based tools for that.

In parallel you can try and run PhotoRec on the backup copy of the disc, as long as you don't change the actual backup copy, just pull any reconstructed files from there and copy them to a new location, outside of the backup.

It is difficult to give you very concrete steps to take as much depends on the actual partitioning and filesystem types, sorry for that. I hope this helps you on the way to get some of your data restored. (Did I mention to make a backup of your disc before trying any changes?)

Anthon
  • 79,293
  • +1 for backup. It's practically never too late to backup. – user Nov 06 '14 at 09:51
  • The problem if the partition was formatted with FAT is that FAT stores all its critical data structures very early within the partition. NTFS is better in that regard in this particular case; IIRC it stores the MFT in the center of the partition (it does this to minimize the seek times to jump between user data and MFT), which means that all the critical file system data in that case is highly likely to be intact and only the partition table plus a few gigabytes of user data is lost. The partition table is likely to just have been all disk as one big partition, which makes that part easy. – user Nov 06 '14 at 09:53
  • @MichaelKjörling That is what I remember from (V)FAT as well. I can only hope there are multiple partitions. – Anthon Nov 06 '14 at 09:56
  • No I just had 1 primary partition where I stored all de data and mybe I confused you a bit! With HDD I ment an external Harddrive which is formatted as NTFS. Sry for that. – Eric Croiset Nov 06 '14 at 10:39
  • @EricCroiset No problem, it was just a bit guesswork. As Michael indicated, NTFS should give you more restore capabilities. Recreating the partition table with one partition should be relatively easy to do, assuming the partition took the whole disc. – Anthon Nov 06 '14 at 10:44