0

I tried to delete all files named "Thumbs.db" with something like

$ rm -rd /path/to/hdd/decrypted/folder/* --name Thumbs.db

but it just started deleting in alphabetical order. Now, I have to recover the files, which are still on the HDD, but

  1. they're encrypted

and

  1. I meanwhile shut down my computer and unplugged the hdd before.

Is there a way doing it?

I tried testdisk and photorec as stated in comments, which worked somehow for the not-first try.

But I'd like to have my files restored in the (sub)folders they've been, not just naked files themselves.

5
  • 3
    Before you execute scripts, use them in lab enviroment. Test your scripts.
    – ilansch
    Commented Aug 22, 2017 at 11:08
  • This helps me for next time preventing, but doesn't face the actual problem. Is there a tool finding files on a esp. encrypted hdd when the bytes themselves are still there?
    – Nepumuk
    Commented Aug 22, 2017 at 11:24
  • 3
    That the files were on an encrypted filesystem should be irrelevant if you can access the decrypted image. Assuming this, any normal method for attempting undeletion can be attempted. Just remember to use the decrypted block device rather than the underlying encrypted one. Commented Aug 22, 2017 at 11:50
  • I tried testdisk and photorec. Both gave the output: Unable to open file or device /path/to/decrypted/dir/: Inappropriate ioctl for device
    – Nepumuk
    Commented Aug 22, 2017 at 13:32
  • 1
    Neither of these tools wants a filesystem path. They want a block device. Like I said, point them at the decrypted block device. Commented Sep 1, 2017 at 16:54

1 Answer 1

1

At first, you should never mount your disk read-write during the recovery. Then you may copy the decrypted device (in /dev/mapper/foo-crypt) to an unencrypted device if you have some tools which only work with real disks. For usual linux utilities /dev/mapper/foo-crypt) should be okay.

Then testdisk and photorec are good choices and if you i.e. need some important text document you can even try with dd and grep cutting different parts of the image and trying to find the information.

The good news is, that most data probably is still there. The bad news is, that filenames and directory names often are gone, how much can be recovered depends on your filesystem. The classic windows approach was (with FAT32) to replace the first byte of the filename with 0, so the filenames were almost intact. ext2/3/4 destroys inodes completely as far as i know. So there you probably won't find such metadata, but tools like testdisk should be able to extract fileformats they know from the raw data in the partition.

You may be able to restore directory structure, if you find any files containing it. Look out for example for the locate(1) database, indexes of desktop search engines, recent files entries in gnome/kde/different programs, etc.

You probably will have to sort the restored files into the found directory structure yourself.

2
  • Although I got a bunch of files, the ones I was looking for didn't appear. Many if not most of the found files are corrupted. Many of them cannot be opened, some are just partially there. What now?
    – Nepumuk
    Commented Nov 13, 2017 at 9:49
  • testdisk and photorec are good tools, if they don't help I would think there is little chance of getting more back without much efford. You can try to work on block level (searching for known fragments of your files and cutting them out of the raw data). Possibly you could pay some data recovery company they have more experience doing such things. But read reviews about them, not all have the same level of competence.
    – allo
    Commented Nov 13, 2017 at 10:03

You must log in to answer this question.

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