Okay, so I own a solid state drive (for my operating system) and a hard drive (for everything else). I was reinstalling Debian GNU/Linux after I messed something up and, in a hurry, I accidentally ticked the encryption option for my hard drive (sdb), when I only meant to encrypt all of my partitions for my solid state drive (sda). When I was writing random data to my partitions, I got to sdb1 and realized I didn't want to overwrite that. So I canceled it before doing anything to it. I fixed the mistake, or thought I did, and finished my installation only encrypting my sda partitions.

Well, after I booted into Debian, my first reaction was to check out my hard drive, to see if everything is okay. It asked for a password, which I gave my normal password to unlock the encryptions. After I did so, it gave me an error and told me something (I can't remember what it was, it's been about a week and it's not currently connected; however, I can check if that's needed). I can't access my files now, though, and I'm wondering how I should go about this. I've attempted TestDisk and it brings back the encryption, I assume. I'm not sure at all what to do. I tried DiskDigger and it shows my files, so I know everything is still okay, but I don't know how to get things back.

I would like this to be as painless as possible. I would try Photorec, but I don't currently have a hard drive which is big enough to fit everything I have on it. Plus, I don't want to go through the trouble of finding every file and fixing things back to how they were folder wise.

I've been searching for a long time for how to fix this and have tried many solutions. I'm not sure how to tl;dr this and it's likely terribly written, I apologize. I need a way to get back my files or remove the encryption. I can give any information needed about this. Thank you!

Restore your backup.

Not following you.

Is SDB encrypted or not?

There should be no such thing as "brings back the encryption"

Besides you're not saying you forgot the encryption password or accidentally set it to something that you aren't able to replicate.

What I'm reading instead is:

"When I was writing random data to my partitions, I got to sdb1 and realized I didn't want to overwrite that. So I canceled it before doing anything to it."

At what point during a Debian install is the part where one writes random data to their partitions?

What I'm hearing instead is that you partially overwrote your data.

I don't know DiskDigger, but you say it shows your files. Use it to retrieve them if you can.

Use Photorec and note that you can use Photorec on just a partition in the event that you don't have a suitably large enough location to perform the retrieval. In my humble opinion, you can purchase a USB external HD in the terrabyte size range for cheap money, granted not free.

This problem is any of:

1. Encryption only, which means unless you have the key and password, you can't retrieve the data
2. Data corruption, which means you can try to use backup retrieval software, but you'll have to find drive space to do this with
3. Combination of the two, encryption and data corruption = you probably can't retrieve the data

Wonder if there is a way to clone off using clonezilla or such and then re-apply with some changes to backup config???

Gparted could clone off file by file for you to apply it back.


Doing it in small batches by shrinking what you have and slowly moving stuff over may work.

May be a way to do it in place but I've not read it.

How would I do that?


I'm sorry, I'm bad at explaining. I have no clue if it's encrypted or not. It may be. What I meant was it brings back the encrypted partition, with no option of the unencrypted partition I had prior to it in TestDisk. I believe I'm using the correct encryption passphrase, so that shouldn't be the issue.

Whenever you encrypt your partitions for the installation, all data is written to zeros. It's to harden the encryption or something of the sort. Afaik no data has been overwritten.

Well, DiskDigger runs in mono and crashes every time I've tried. Also, I found out that it's proprietary software, despite what I had previously thought; therefore, I'd prefer not using it.

I had about 1.6TB of data, so I couldn't easily use separate partitions for this type of scenario. I'll look into an external drive, though, if needed.

You have to had saved a backup first. Sounds like you didn't.

A suggestion is that if you need your system up and running, and have an available small disk somewhere, so you can leave this one aside for now until you end up buying a secondary external storage disk, then do that. Which is to use some other disk just to get the operating system back up and running and don't use the disk where your data is until such point that you can attack that larger project by using something like PhotoRec and a larger drive for the restore attempt.

It all boils down to how irreplaceable your data is, and most of it usually is. For future suggestions, things like scripts, configure files, bookmarks, pictures, movies, etc, I keep multiple copies of them. I buy new 1TB or 2TB disks and copy my archives into them and add my new stuff. I end up keeping the old copy. Which does mean that I usually only have one or two places where my most newest stuff is copied, but eventually it does get backed up using this form. Further, since stuff comes of a camera, usually the originals are on the phone, in an email, or on an SD card/Compact Flash from the camera or elsewhere. That is the most recent stuff. The older stuff is already part of my moving archive where I just keep a copy of. Plus all the thumb sticks and such I may use to transfer stuff.

If you don't have a backup, then you don't, ergo restoring it is not possible.

The other suggestion is to be more regimented about how you progress when you do a new install. Use a new disk to ensure that a large body of data such as that does not get affected. Leave that large body of data on a different disk, and not attached to the system while you install the new version of Linux.

Personally I keep my data entirely separate in USB external drives and only attach them after I have done any OS changes and/or new installs.

What would have happened is that the first 1 to 2 megabytes of the partition would be overwritten with the LUKS header.

If the partition is still the same size and in the same place, you don't even need to use testdisk to recover the partition table. If the old filesystem was ext2/3/4, you can just use fsck.ext2 to recover the super block and fix the primary group descriptors. The only remaining problem is that the ext2/3/4 primary super block is the second 1K block in its partition, so the first kilobyte of the LUKS header still remains, and the system is going to see that if you try to mount the partition without explicitly specifying the filesystem type. (Running "mount -t ext4 ..." should work OK. Substitute the correct type if it's not "ext4".) You can get rid of that LUKS header remnant by running "dd if=/dev/zero count=2 of=/dev/sd{X}1", replacing "sd{X}1" with the appropriate drive and partition.

Note that running fsck.ext2 is potentially a destructive operation if things do not go well. You really should have a backup image of the entire partition before doing that.

I don't think so. If the filesystem metadata has been corrupted, fsck will abort - the OP would have to explicity us an alternate superblock(s).
I have used "mkfs -S ..." (capital S) to recover these sort of issues in the past. Read the warnings in the manpage, and only try on an imaged copy.

Since I actually tested that by creating a 25GB ext4 filesystem on /dev/sde1, loading it with several gigabytes of data, then unmounting it and running "cryptsetup luksFormat /dev/sde1" on the partition, and finding that "fsck.ext4 /dev/sde1" recovered the filesystem completely with only a modest number of "y" responses needed (I almost never use "fsck -y ...".), I stand by what I posted. fsck automatically located and used a backup super block.

The recovered filesystem mounted successfully with "mount -t ext4 /dev/sde1 /mnt/tmp", and the contents of all the files matched the originals. It took "dd if=/dev/zero count=2 of=/dev/sde1" to allow mounting without the "-t ext4".

1 members found this post helpful.

Thanks - live and learn.