So, I did a thing - accidentally selected my 5TB external NTFS hard drive (encrypted with VeraCrypt) as the target for writing an ISO. The moment I noticed that “Impression” had switched the drive letter, I immediately killed the process. But yeah… damage done.
Now, the situation:
- Currently shows up as:
- 6 MB FAT
- 4.3 GB
- 2 TB unallocated
- 2.6TB unallocated
- The VeraCrypt volume obviously no longer mounts.
- Drive was somewhat crucial - lots of structured data I’d really prefer to recover with the original file system intact.
I know chances are slim, especially with encrypted volumes, but has anyone had luck recovering from something like this? I’m open to commercial recovery tools or command-line wizardry. Would love to hear from anyone who’s been down this road.
Any thoughts or recommendations?
Any thoughts or recommendations?
Tap for spoiler
Backup important data
Veracrypt has back-up headers located elsewhere in the volume that are unlikely to have been overwritten.
First thing’s first I would strongly recommend copying the drive as it currently exists bit for bit to another drive of equal or larger size. Don’t work on the original if you can help it.
Now with this copy, you should try to check the option to use the backup header when mounting and try again. If the partition is gone and veracrypt doesn’t see it you’ll need to try using something that recovers partitions and doesn’t mind encrypted partitions or partitions or file system types it doesn’t understand and use that to ON THE COPY recover and recreate the partition (this will write data and can cause the possibility of further loss or worsen your ability to recover which is why it is important to perform it on a copy). Testdesk may work for this but there are other options that probably are better.
See this list: https://old.reddit.com/r/datarecovery/wiki/software and choose something from there if this data is truly important. Again only work on a copy on another drive. Some of these software examples actually work against the original drive and make a copy elsewhere and should be safe to use on the original drive so long as they have you select a target drive to push the recovered data to but read the documentation. Testdisk absolutely must be used on a copy.
You will incur data loss and likely should run one of the file recovery software mentioned on the drive once successfully mounted in veracrypt to attempt to recover as much as possible.
Thank you so much, this is really helpful.
I have a slightly different issue where I have several VeraCrypt vaults on an external that seem corrupted and don’t recognize the correct passwords anymore. I’m making note of your advice to work on mine too. Is there anything particularly different you would recommend?
The only thing I would note is -IF- your volumes are not partition or disk based BUT -files- based there is the possibility that corruption of the host file system of the disk the files containing the volumes are on could result in pieces of those files being marked unreadable by the disk and it’s POSSIBLE one way to solve this would be a file system check utility.
HOWEVER such activities carry a -large- risk of data loss so I would advise a bit for bit copy of the disk and doing the repair on that so if it goes wrong you’re not worse off. -IF- you cannot make a copy then I would advise at least trying to mount using backup headers before doing that and copying off anything you can salvage as file system checks can really mess up data recovery and should only be used in certain circumstances.
You’re much better off trying the recovery software I linked in fact than doing a file system check as it will tend to have better results.
You can also use the option to mount as read only in VC to prevent writes to a suspected failing disk.
Let me know if you need further advice.
I’m gonna be the one to say it. You’ve ruined your ability to decrypt the data. You can try a recovery service but expect to pay a lot for zero results.
I’m sorry this happened to you.
Edit: don’t go with commercial software, find a recovery service
expect to pay a lot for zero results
Industry standard for data recovery specialists is “no data, no charge”
Here this is not the case at all.
Where is “here”?
You might want to check out the member listings at https://www.datarecoveryprofessionals.org/
These organizations generally seem to hold themselves to a “better” standard than the rest of the industry.
Drive Savers has a cleanroom. They got my data back in 2001 or 2002. It costs a lot.
This case is due to a logical problem. Cleanrooms are only necessary for physical repairs, like swapping the Head Stack Assembly.
DriveSavers’ cost of entry for a successful recovery is about $2,000. They’ve even given that quote to an iPhone user who needed nothing more than a screen replacement.
Their “state of the art facility” is appropriate for hardware cases where money is no object and you need the best of the best to deliver results no matter the cost.
Realistically, most regular people will be well taken care of using a reasonably priced service like 300 Dollar Data Recovery.
VeraCrypt Volume Format Specification:
Each VeraCrypt volume contains an embedded backup header, located at the end of the volume (see above). The header backup is not a copy of the volume header because it is encrypted with a different header key derived using a different salt (see the section Header Key Derivation, Salt, and Iteration Count).
It may be possible to recover the encryption key. You might try asking on VeraCrypt forums/mailing lists or contacting a commercial data recovery service which understands VeraCrypt. Though I’m not familiar with VeraCrypt so I may be misunderstanding the cited documentation.
This is in all likelihood the way to go. These instructions from VeraCrypt might lead the way.
Of course, OP should create an exact duplicate of the disk to another drive before making any changes to it.
As an aside, I know that GPT partition tables likewise come with a backup header at the end of the disk. Whether LUKS encrypted devices also have backup headers, I don’t know, but it doesn’t seem so. So, my fellow LUKS users, perhaps you would like to run the following:
sudo cryptsetup luksHeaderBackup /dev/LUKSDEVICE --header-backup-file ~/nas/backups/lenovo_x280.luks.bin
I think you need to go commercial recovery. If it was a file you accidentally deleted, that can easily be recovered, but you wrote directly to the device.
My condolences. That data is now gone, I suggest you square yourself with that and move on. Save yourself a lot of grief and time.
If you have your encryption key backed up, you have a chance to decrypt it still. It’s also possible, but unlikely, the key somehow survived the ISO write and it was written elsewhere on the drive, allowing the key to be recovered. I would only trust such with a professional. (There is basically a smaller encrypted section that your typed-in password decrypts, that section contains the encryption key the rest of the drive uses.)
Honestly though, if you have your stuff backed up (you do have your stuff backed up elsewhere?!?), just restore from your backup and call this a loss.
If you don’t have a backup, this was your wakeup call. Always have a backup going forward.
Aren’t encryption keys, typically in the partition header? Wouldn’t that be one of the first things overwritten? Even if it was in the FAT or in the GUID, it would have been overwritten when a the ISO was written.
Yeah, it’s very unlikely it survived.
First thing it did was overwrite the partition table and everything else with that, to make its own, since it could disregard all the existing data.
I agree with the other commenter, commercial recovery, if the data was that crucial.
I guess it’s a question of how much hassle it’s worth. I did a messy data recovery of a crashed database for a work client once, but it involved a lot of trial and error and writing special purpose code, plus considerable luck that some things worked better than I had a right to expect. Cost of something like that would be in the multi kilobucks, maybe low 5 figures. We got almost all the data back, though not 100%.
Maybe just put that HDD aside and replace it with a new one, and deal slowly with recovering the data as you get the time to mess with it. Also don’t do any write operations on the old drive. Maybe copy it entirely to someplace and work on the copy. In fact better do that anyway, HD’s physically crash all the time.
If it wasnt encrypted you could have used testdisk app but I dont see how you could decrypt it in this state
