I accidentally deleted a large Folder (about 50GB) from my hard disk that is formatted as ext4. I tried
extundelete but it claims that nothing is recoverable. I did immediately unmount the disk when I deleted the folder so it should be there, why isn’t it working?
sudo extundelete /dev/sda1 --restore-all
NOTICE: Extended attributes are not restored. 1114660864 [Data]
Loading filesystem metadata ... 4253 groups loaded. 4096
Loading journal descriptors ... 0 descriptors loaded.
Searching for recoverable inodes in directory / ...
0 recoverable inodes found.
Looking through the directory structure for deleted files ...
0 recoverable inodes still lost.
No files were undeleted.
It should be noted that the partition is on a spinning disk, so it shouldn’t have had time to lose the files.
To add insult to injury, testdisk isn’t showing the deleted folder too…
Possibly try dd or ddrescue to make an image of the device then work with that image to try your recovery. Doing so would avoid potentially writing to the device while attempting recovery. I think ddrescue also comes with an app called photorec that may be able to assist.
Doesn’t this require copying the whole device to separate place? The device is a 1TB HDD. I have nothing that can store this much data (except for this disk)
If imaging the drive is not an option, you can plug it in and umount it immediately, to avoid overwriting data. You can first give PhotoRec a shot, which is sort of a user-friendlier version of TestDisk, provided that the files you want to recover are among the file types recognized by the program (you can also add your own file signatures). However, since you’ve already run TestDisk and found nothing, I would not be very optimistic. I think there is an option in TestDisk to analyze the free space for file fragments, which tends to work better for spinning disks than for SSDs.
My last hope is some sort or deep scan. The good thing is that most of this data is a mirror for data on another device, hovewer the rest of it had no backup, so I have to take this loss if everything fails. Maybe next time I will think twice before shift+del+enter
The thing that disappointed me the most is that I immediatly unmounted the disk when I noticed my fault (in less than a minute) but
extundelete found nothing, neither
testdisk. I wonder how this much data disappeared from a spinning media this fast.
You can use dd or ddrescue on a partition rather than a full drive.
The partition is about 500gb,the second largest drive I have is 250 GB nvme (my system drive) so I can’t do that too.
Gnu ddrescue has an -s flag causing it to save the image as a sparse file. That way, the image size is close to that of the actual data on the disk, not that of the partition size.
Thanks for the info (you actually answered another question I had in mind), but doesn’t this defeat the purpose of the image? If you skip the free space it won’t have the needed data to recover.
I will just accept the data loss, most of that data was a backup so I can run the backup again, but also some of it isn’t.
The program copies all the non-zero blocks of a disk, so in theory, even when saving to a sparse image file, deleted, but not overwritten file fragments should end up in the image. This is why the final image size could be larger than the amount of data on the disk. If you fill up your 500GB partition, delete half the files and then immediately image the drive, you will end up with a 500GB image, even though the system reports 250GB of data on it. The sparse file option is useful when you want to make full-metal backups, especially when you are working with a failing disk and don’t have enough storage space to transfer the partitions in their entirety (or if you just want to save some space).
OK I will probably try it later thanks
Just to be clear, if you don’t have an urgent reason to work with an image file (e.g. failing drive, need to repurpose it, etc.), you can work directly with the drive. Again, if TestDisk cannot recover the file from the disk, it probably won’t discover something in the image file.