this post was submitted on 26 Jun 2025
47 points (100.0% liked)

Linux

55679 readers
572 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
 

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?

top 14 comments
sorted by: hot top controversial new old
[–] [email protected] 14 points 10 hours ago (1 children)

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 have to run a file system checker on the drive once successfully mounted.

[–] [email protected] 3 points 7 hours ago

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?

[–] [email protected] 5 points 15 hours ago

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.

[–] [email protected] 33 points 16 hours ago* (last edited 16 hours ago) (1 children)

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.

[–] [email protected] 15 points 15 hours ago* (last edited 15 hours ago)

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

[–] [email protected] 12 points 16 hours ago

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.

[–] [email protected] 14 points 16 hours ago* (last edited 16 hours ago) (1 children)

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.

[–] [email protected] 7 points 16 hours ago* (last edited 16 hours ago) (1 children)

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.

[–] [email protected] 1 points 16 hours ago

Yeah, it's very unlikely it survived.

[–] [email protected] 6 points 16 hours ago

If it wasnt encrypted you could have used testdisk app but I dont see how you could decrypt it in this state

[–] [email protected] 48 points 16 hours ago* (last edited 16 hours ago) (1 children)

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

[–] [email protected] 6 points 15 hours ago

Drive Savers has a cleanroom. They got my data back in 2001 or 2002. It costs a lot.

[–] [email protected] 10 points 17 hours ago

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.

[–] [email protected] 23 points 17 hours ago

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.