The first move should shutdown or unmount the partition, prevent further writing to the storage, then use a secondary system to do the rescue work.
However, in my case, I was inside a virtual host. Here is what I do:
So I tried to do things with minimal steps to avoid crazy disk IO.
Since I am using Debian, here is the command to install:
sudo apt install testdisk
As the filesystem was formated with ext4, I thought I could give
extundelete a try; unfortunately, there is a permission error. And I didn’t spend time dig deeper.
testdisk didn’t work for me, and I don’t know why. It shows the partition, but I cannot get to the step to restoring files.
photorecfrom the testdisk package
testdiskcomes with a tool call
photorecwith different approach, which works perfectly.
Then I created a new folder, follow the screen and run the restoring.
And to save time, I open a second terminal session to do
grepin the same folder, as I am only looking for one file.
This accident gave me an idea, so maybe in the future, if this unfortunate event happened again, I can leave a unique string inside the script, so it will be easier to track down from restored files.
Also, one thing pop in my head, so if you didn’t
shred the file, it would always be possible to recover, so maybe next time, I should wipe the disk before I shut down my virtual hosts.
Overall, don’t work on a production server when you do not have enough sleep, and keep things encrypted.