Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I had an 1.5TB exteral disk, with an 983.83 GB ext3 partition on it, where the partition was positioned such that there were approximately 400 GB free space before the ext3 partition.

I then used Minitool Partition Wizard to move the partition to the start of the drive, but unfortunately the cable was ripped out from the drive at 54% completion.

Now the drive simply shows an unknown partition where the ext3 partition used to be.

I had a look at the situation using Partition Wizard's Partition Recovery, and it detects the an ext3 partition at the new location, as well as an unknown partition at the old location.

Since I have moved the partition to the start of the drive I suspect that it would be possible to continue the process in some way, the partition overlap, but there should be a sufficient offset between the locations, such that all the data should still be on the disk, though it is cut in two parts.

I have two ideas to how to fix the problem, but I'm not sure how I would make it happen.

The first idea is to simply copy the rest of the partition to the new location and then undelete the partition, such that it would show up again. It seems it would be the easiest way to fix the problem.

The second idea was to recover the partition at the new location, and then resize the partition to fill the entire drive and finally try to undelete the files, but I'm not sure this is even possible.

Does anyone of you have a good idea of how one of these ideas could be accomplished?

Alternative ideas to recover the partition would also be greatly appreciated.

EDIT: Clarified information about partition size and overlap.

share|improve this question
up vote 1 down vote accepted

OK, I don't know minitool, so I'll assume that it does the obvious thing: copy bytes sequentially and adjust metadata, either up front or afterwards.

You can use fdisk -l to see what state your partition table is in. It should either report a partition at the old location, or at the new location. Things might be easiest for you if you were to recover the partition in the location the metadata indicates.

You write that “there should not be any of the actual data which have been overwritten”. Does that mean that the whole partition is smaller than 400GB, in other words, that the old and the new location do not overlap? If so, you may skip the rest of this answer.

Otherwise I'd try to work out the offset of the move: by what distance were your sectors supposedly copied? The recovery output should give you a good indication there. If you have that worked out, I'd try to search for some overlap: using dd you can read arbitrary portions of your drive content. Do so at two locations exactly that offset apart from one another, and pipe the result to some hash function like md5sum. If your offset is correct, and the lower location contains bytes already copied while the higher location contains the source of those same bytes before copying, then the data and hence the hash should agree. In that case, you could simply copy the remaining data using the same offset, in order to either complete or undo the transfer, depending on the intended location of the recovered data which you have decided on above.

share|improve this answer
I clarified my post a bit; Yes, the new and old locations overlap, but my logic tells me, that there should be at least an entire copy of all the data on the disk. – FrederikNS Jul 16 '12 at 13:40
Sorry for the late acceptance, but this worked like a charm, maybe it would be a good idea to make a simple tool to do this, to help people with less technical knowledge? seems quite simple – FrederikNS Aug 3 '12 at 8:35
@FrederikNS, thanks for the acceptance. As long as it isn't me making this tool… A dedicated program could avoid the hashing, and instead scan the disk at two positions in parallel, maintaining a count of matching bytes or blocks which gets reset to zero every time a difference is detected. One could continue either until a predefined threshold or, even better, until the largest matching sequence has been identified. Would be nice, but I don't have the time, and I'm unsure how often it would be needed. – MvG Aug 3 '12 at 8:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .