This is something I recommend you never (ever) have to learn. Do good backups. Don't accidentally delete stuff. I do passable backups. But I'd been tweaking the settings for this new Pelican-based blog for most of a day (three to five hours work, some not obvious) when I decided to delete the blog's generated files. So I typed:
rm -r content/*
which complained that there was no content ... At which point I'm clutching my head and screaming. For those not familiar with Pelican blogs, generated files go in the "output/" folder. The pages you wrote - from which files are built - are stored under "content/". So I'd just wiped out several hours work.
I shut down the entire system immediately - I did NOT search for how to fix it in my web browser before doing so. You don't want to cause any disc writes that might over-write the deleted files, and web browsers like to write to a cache. In fact, I've seen it recommended that you just immediately press and hold your power button until the machine turns off, don't even do a clean shutdown. I'm of two minds on that one, because then you're dealing with a filesystem that wasn't unmounted cleanly. I chose the clean shutdown.
Next step: get out another computer, fire it up, and install extundelete (readily available as a package in the world of Debian and derivatives). Read the man page first (I didn't).
Remove the hard drive with the deleted files from its home computer. Attach it to the computer with extundelete on it via a SATA-to-USB cable or equivalent. For me, one of the ugly bits was that I'd read that extundelete wanted to work on the raw device, not a mounted partition ... but how does that work when the partition with deleted files is crypt-luks? But I'd also read that someone had used extundelete without unmounting the partition and it worked. So as a compromise, I ran (as a regular user):
pmount -r /dev/sdb9 delhome
That mounted the partition read-only. So I tried (as root):
It complained at me:
No action specified; implying --superblock.
extundelete: "/media/delhome/w/public_html/blog/content/" is a directory. You need to use the raw filesystem device (or a copy thereof).
At which point I actually went and read the man page. The correct command turned out to be this:
extundelete --restore-directory w/public_html/blog/content/ /dev/mapper/_dev_sdb9
This time it took quite a while (30-45 seconds?), and then dumped a bunch of files (with full directory structure) into the "RECOVERED_FILES/" folder in the folder I ran the command from. It recovered all the files I wanted and some vim swp files as a nice extra.
I hope you never need to know this. But if you do, I hope it works as painlessly for you as it did for me. Next time I think I would shut all applications, log out the user, log in as root, and remount ro /home/ (assuming, of course, the deleted files were under /home/ and /home/ was a separate partition - as was the case here). This has the same risks as doing a clean shutdown: the system will be executing actions that might write to disk.