This project has moved and is read-only. For the latest updates, please go here.

[Solved] Disk failure during in-place encrypt. Any way to get things back?

Topics: Technical Issues
Mar 18, 2015 at 2:14 AM
Hey everyone,

So this weekend I started encrypting my 2TB external harddrive. I've had the disk for ages and was encrypting it mostly for nerd curiosity.

At about 44%, I got a message asking if Veracrypt can zero a few bad sectors. I said ok, but the encryption then fails with a hardware error.

If I resume the process, Veracrypt again asks to zero some sectors (but the number of sectors changes every time) and again fails.

So I now have a disk with lots of information on it (that I would love to recover if possible).

Is there any way to cancel a stalled encrypt?
If not, what is the best way to recover whatever is left?

Can I somehow repair the disk so that the encrypt can finish?
Can I mount the 44% of the disk that is encrypted?
Should I try to use TestDisk to restore the partition table?
Should I use PhotoRec to pull anything that it can find?

Thanks in advance.
Mar 18, 2015 at 4:33 AM
Edited Mar 18, 2015 at 9:33 AM
This is why I HATE external USB drives. Nothing but problems. If it's a hardware error issue like you say, not much you can do. On the other hand, If it's a USB drive it could be an issue with the USB controller itself. (The controller that's built into the USB enclosure itself) I've had the controllers go bad on me while the drive inside was fine. It's worth opining the enclosure and taking the drive out and plugging it into your system directly assuming it's a 3.5 SATA, or IDE drive? This has worked for me. You can usually do it with the smaller laptop drive that are in the external enclosures, but you might need an adapter.

But as far as your data, I hope that you made a backup (clone) of the drive before you started encrypting it. Nothing personal, but I don't understand why people trust drives with their important data. Drives have a habit of going bad without warning. You should do backup clone syncs often with something like this:
Mar 18, 2015 at 9:18 PM
The drive hasn't failed outright. It still responds when it is plugged in, but there seems to be a bunch of bad sectors that don't allow Veracrypt to continue encryption.

I had had pretty good luck with the drive, but as I say, it is old. I tried running the WD Diagnostics tool's Media Scan and it failed with a "too many bad sectors" message. Looks like the thing is pooched (or at least was on the way to being pooched).

I will try and see if I can get anything off of it! Thanks for the tips, movingkey.
Mar 19, 2015 at 4:35 AM
Edited Mar 19, 2015 at 4:38 AM
Hi! A person at wilderssecurity had a similar problem. Maybe this link will help you! You need to hex edit, watch the second posting:
Mar 23, 2015 at 5:12 PM
Thanks for the response RyXaLRoot. It is all over my head, but I'll tinker and see if I can get something figured out.
Jun 13, 2015 at 10:16 PM
Hi everyone, here I come a couple months later, but I just wanted to update this post with a solution that I found (for the good of the internet!) ;)
  1. I bought another harddrive the same size as the one that failed (2TB).
  2. I used GNU ddrescue (under Linux) to clone the old drive to the new drive (commands below). This step took about 4 days in total!
  3. I restarted the encryption process through the Veracrypt menu, and the new drive picked up where the old one left off. Currenly encrypting with 23 hours left.
To use ddrescue, I ran it twice, making sure to use a logfile both times. The first command copies all of the good blocks first, to avoid hammering on bad blocks and possible losing more data:
ddrescue -v -n --force <path to old drive> <path to new drive> <name of log file>
The second command gets into the nitty gritty in the bad blocks and tries to salvage anything it can.
ddrescue -v -r1 --force <path to old drive> <path to new drive> <name of log file>
Because we are using a log file, you can repeat or pause and restart the commands as many times as you like and ddrescue won't go back and recover the parts that it has already recovered.
Marked as answer by ConIA on 6/13/2015 at 2:17 PM