This is one of the reasons why we have infrastructure as code now, so system changes can be reviewed and tested just like application code, and more types of accidents can be reverted via source control :)
In the article the guy is using ansible. He even had off-site backups, but they were mounted before his ansible playbooks ran, wiping them out as well.
Another dangerous command is `crontab` with no arguments. It reads a new crontab from standard input. If you type Ctrl-C, it will abort and leave your existing crontab in place. If you type Ctrl-D, you've just created a new empty crontab and clobbered your old one.
My personal crontab is in a separate file in a source control system. I don't use `crontab -e`; I edit that file and feed it to the `crontab` command.
(It would be nice if HN handled backticks the way they're done in Markdown.)
A customer did this on his server once while I sat with him to add something. Since restoring the crontab from backups would have been a little inconvenient for such a small thing, I grepped the log files what commands were run by cron in what interval and had it rewritten in a few minutes.
I've managed that one as well. One month into a new job and working on servers with complex applications installed that I wasn't yet familiar with. Thankfully I had `crontab -l` just beforehand, otherwise I'd have been screwed.
Indeed. I do generally keep backups of crontabs, not just in case of this kind of scenario but also in case the platform blows up in any unexpected ways. Sadly the company in question didn't. However I have since made it a personal policy to always -l before editing so I have a "backup" in my tmux scroll back (that time I mentioned before, it was pure chance that I had -l)
Some platforms it's -r, others it's -d. I suspect it's down to which cron daemon you run but never really cared enough to investigate. In any case, both are next to the 'e' key so either are just as dangerous in terms of typos.
Those two letters are eerily too close to eachother.