ext4 undelete

[jlx1784]

Hi,
yesterday I accidentally deleted lot of vacation photos, on ext4 with 64bit flag set....
in the past I used Testdisk that recovered files on some exfat (if I remember), but since it's ext4 testdisk don't provide undelete menu...

I tried extundelet, ext4magic but both are outdated, no more maintained, and even warned against use by developer for ext4magic..... Didn't work, ended using photorec that restored a few of them and a lot of old (and even not deleted) photo, so, now I have a bunch of duplicated files... and lot of loss

We don't have any solution for ext4, and today this is the most used filesystem on linux

I'm ready to financially participate to ext4 support in testdisk, really, loosing memories is more valuable than anything, I'm sure that lot of people would do also.
is there an impossibility to recover file on ext4 like on ext2?

thanks and regards

[recuperation]

Interesting! How much will your participation be?

[jlx1784]

how much will it take to implement?

[jlx1784]

I'm low income right now, so at most I can put 100€ now... maybe others can join?

[cgrenier]

https://www.cgsecurity.org/testdisk_doc ... torec.html give some tips on how to deal with duplicated files
PhotoRec can skip the allocated blocks, so if it recover a file that is not deleted, it's because it has recovered a deleted copy...

ext3 and ext4 purge the metadata when a file is deleted, it's why it's not possible to develop a reliable undelete for ext4 like it was done for ext2.
Analyzing the ext4 journal is already what extundelete/ext4magic are doing. I have no good idea to improve the situation.

Note that most Linux distributions run fstrim on SSD once a week, so data recovery is more and more unreliable.

[recuperation]

I'm low income right now, so at most I can put 100€ now... maybe others can join?

Thank you for your willingness to support TestDisk!

What you did not mention in your initial posting ist the technology of your disk, HDD or SSD? On an modern operating system TRIM will eradicate your deleted data.
Even in case of an HDD you might be affected if your HDD is a SMR disk. Those seem to exhibit flash-type behavior as a consequence of the overlapping tracks.

[jlx1784]

16.1.2025 12:37 recuperation: modified SDD->SSD

I'm on SSD, but seems that data is not TRIM, maybe because I use LUKS on top of the SSD
with photorec, I recovered TONS of oldies (sadely not what I searched, Lost about 50% of the deleted files (that was about 300MB), but recovered 15GB of photos I sorted 3 months ago )
so the data was there, maybe not fully recoverable, but since I can't have a view of deleted files in the directory, I'm not sure
and more, now I have 15GB of data to double check (is it photo I deleted? do I have the copy? is it duplicated? should I restore it or not? why is it deleted? because of a copy/move/recompressed to avif?) and don't know when I could do such a huge work... I already have some photorec archive done 10 years ago when my hdd died...

[jlx1784]

https://www.cgsecurity.org/testdisk_doc ... torec.html give some tips on how to deal with duplicated files
PhotoRec can skip the allocated blocks, so if it recover a file that is not deleted, it's because it has recovered a deleted copy...

ext3 and ext4 purge the metadata when a file is deleted, it's why it's not possible to develop a reliable undelete for ext4 like it was done for ext2.
Analyzing the ext4 journal is already what extundelete/ext4magic are doing. I have no good idea to improve the situation.

Note that most Linux distributions run fstrim on SSD once a week, so data recovery is more and more unreliable.

:/ that's really bad news... I wonder if I should move to btfs.... it has an undelete script https://github.com/danthem/undelete-btrfs