What to do after a "rm -R /*"

Question

I was working on my website under root and I commit the worst thing that a linux user can do : rm -R /* instead of rm -R ./*. I've stopped the process when I saw that it was taking too long... I manage to reinstall lubuntu with an usb key, is this a good idea or are there other ways to reverse this big mistake ?

Thanks to any answer

Burnight

I hate to say it, given the severity of your type-o. I feel for ya man. But this question is best suited for serverfault.com – Sixtasixteen

Ok... Thanks anymay... I'll try to reinstall lubuntu via a USB key – Burnight

there's nothing to do, since nothing is the only thing you will have after a rm -R /* :D – Yeast

Ok, I've reinstalled lubuntu and now if someone has the trick to avoid the deadly command, post it – Burnight

the classic way to avoid accidental rm / is: ensure that you never have more access than is necessary. find ways to work without sudo / root. macOS goes a little further: System Integrity Protection ensures that even as root, the user lacks the privilege to delete system files. consider describing your entire system using Docker containers; it lets you create reproducible, sandboxed subsystems. your machine's only responsibility would be to start a Docker daemon. then with non-root privileges: you can start up Docker containers (e.g. for a webserver service or database service). – Catenane

I've taken the habit of always executing an ls instead of rm when it could be destructive. After checking the output, I just have two chars to replace in the previous command... small price to pay! – Jay

Answer 1

Short answer: no.

Long answer: depends on the filesystem and on how rm is implemented. It's possible that rm merely unlinks the file; the inode (marked "deleted") and data may still remain. And even if the inode is hard-deleted, the data may remain. But in either case: there is a risk that your actions since that time have already written data over your old data or over the location of the soft-deleted inode. This can happen even with temporary files, or file descriptors (such as for sockets or processes) or pagefile [well, unless that thing has its own partition].

I wouldn't recommend trying to relink soft-deleted inodes, or infer from your data how to reconstruct hard-deleted inodes. Sure, maybe for irreplaceable memories this would be worth it (take the drive to a data forensics specialist), but there's near-guaranteed corruption somewhere on the disk. I would certainly not attempt to run a production system off a disk recovered like that.

I recommend one of the following:

• restoring from your regularly-scheduled backup
• wiping everything and starting again (you have all your website files stored under source control and stored remotely, right?)
• redeploying your Docker image (this was an immutable deployment, right?)

Catenane

Well, it's hard for me because I had no backups and I corrupt the OS, I wipped everything and I started again, if someone is interested to follow the reconstruction of the hole server : teamiskog.ddns.net – Burnight

I've described some recommendations in a reply to your similar comment above – Catenane