Linux

They noticed they accidentally removed a 35GB folder full of media files from a very big vacation, including nature photography and some strange GoPro format files. Valuable stuff.

Are you sure the files were actually deleted? I used to work in helpdesk back in the day and would regularly get calls from users in similar situations, and 9 out of 10 times the folder wasn't actually deleted but accidentally moved to somewhere else - Windows Explorer is dumb like that, it's very easy to accidentally drag-drop a large folder elsewhere without any confirmation - just a flick of the wrist and you wouldn't even notice it. On the other hand, actually deleting a large folder not only presents a confirmation dialog, it also takes a long time to delete the files - and you'd notice it very quickly (unless you were AFK).

So I'd recommend running a thorough search first - both on the old drive and new drive.

But if the files were actually deleted, I also second the recommendation of Recuva - IMO it just works better on NTFS drives, compared to Phtotorec. After all, if the photos are really that valuable then you really should be using the best tools available at your disposal.

1 - This sounds really stupid, but check the recycle bin on both drives 😅 it is windows after all.

2 - turn off photorec paranoid mode, only check for formts you actually want, and sort the output by size to look for actual files you want.

3 - try checking total file size to see if the files were moved not deleted

So, I'm not sure if the process has changed in the last decade or so but in a long-ago computer forensics class step 0, before all else, was to never operate data recovery on the original disk. Create a block level image of the entire device, then work on that.

My go to steps for recovery have been the following in the years since:

1. create an image of the entire disk (not a partition) using ddrescue ddrescue -d /dev/sdX <path_to_image>.img
2. Run test disk on it selecting the partitions as necessary testdisk <path_to_image>.img

If the disk has a complicated partition layout, or more effort is required to find the correct partition you can also mount parts of the disk.

1. create an image of the entire disk (not a partition) using ddrescue

   ddrescue -d /dev/sdX <path_to_image>.img

2. Mount the image as a loopback device with the appropriate offset

   losetup --offset <some_offset_like_8192> --show -v -r -f -P <path_to_image>.img this will mount individual partitions:

   loop58        7:58   0 465.8G  1 loop
   ├─loop58p1  259:7    0   1.5G  1 part
   ├─loop58p2  259:8    0 450.6G  1 part
   └─loop58p3  259:9    0  13.7G  1 part
   

3. Then operate testdisk on whatever partition you want.

All that said there are a lot of variables here and things don't always work perfectly. I hope you do find a way to recover them.

Also, are there any modern recovery tools out there, that promise better reliability?

If Recuva didn't work, then you'd need to use a professional tool such as Runtime Software's GetDataBack. They've been working on it for over two decades - all the way since 2001, and I've used it on a few occasions with good success where TestDisk didn't work. The catch is that it's not free, but you can download the trial version first and run it to see if it can recover (preview) your files. And if the results are promising then you can buy the license and recover the files (no need to rerun the scan).

I agree that you should recover (read), from the original media where the data was, I suspect something is lost along the way with dd when talking about deleted stuff or "marked for deletion".

I hope nobody is using the drive where the data was deleted from, as you may already know that that will decrease any chance of recovery.

I've used Photorec in the past and it was pretty straightforward when it found stuff. I've also used TestDisk to recover corrupted partitions, but I didn't know it could also help recovering files.

You could try Recuva aswell if the data was lost on a Windows machine (I've just noticed the community we're on...)