I accidentally deleted important custom (not known-or-commercial) files from my scientific researches on image processing.

I created the files by collecting raw digital signals from an image sensor.

Then I raw write the file as byte array and there's no "file signature". The only thing is that the first 200 bytes are reserved for QJSON Object that I store with some watermark information and the following image content size.

Is there any way I could recover the files (around 200GB).

I have tried photorec and testdisk, but they find a lot of .txt/.jpg/.bmp files which don't exists on my Operating System

my HDD structure:

sda1 is / -> Ubuntu 14.04 linux root with 57GB ext4
sda2 is extended partition
sda5 is swap partition with 1.5GB
sda6 is /opt with 400GB ext4 formatted with my files on /opt/research-data/rawimages/*.xyz

Extra question: If I dd the hole HDD to a secondary HDD, will the deleted raw images also be dd'ed to the secondary HDD?

What can I do to get my files back?

  • 1
    You can teach custom file formats to photorec but it only is reliable for unfragmented files, and in practise unfragmented often means "small in size". – frostschutz Jan 23 at 17:42
  • 1
    Alternatively, strings -t d -w /dev/partition | grep pattern might help you look for ascii json strings and show you the data offset, so given a plaintext signature, you could script it yourself w/o photorec. – frostschutz Jan 23 at 17:51
  • the hexdump of some other files I have says I have "qbjs" (QJson Object) word on offset 8 and "dateTime" word on offset 34 – shabang Jan 23 at 17:53
  • 1
    Yes, if you dd the whole disk to a second drive you will copy the deleted files as well. If /opt is mounted read/write and you have written anything to /opt (not just /opt/research-data/rawimages) you will probably have destroyed information. So the very first thing to do is get /opt either unmounted. Step 2 is to use dd to copy /dev/sda6 to a new file on another disk. You then read this file 512 bytes at a time, and see if the watermark exists and record the block number and the expected end block based on the length. If there is no overlap you might have identified a file. – icarus Jan 26 at 11:16
  • 1
    You should stop using the disk immediately, every second that you use it, data is being over written. To stop this happening again, look into revision control tools (svn, hg, and maybe git), and backup. – ctrl-alt-delor Jan 27 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.