Man Deletes His Entire Company With One Line of Bad Code (independent.co.uk)

Reader JustAnotherOldGuy writes: Marco Marsala appears to have deleted his entire company with one mistaken piece of code. By accidentally telling his computer to delete everything in his servers, the hosting provider has seemingly removed all trace of his company and the websites that he looks after for his customers. Marsala wrote on a Centos help forum, "I run a small hosting provider with more or less 1535 customers and I use Ansible to automate some operations to be run on all servers. Last night I accidentally ran, on all servers, a Bash script with a rm -rf {foo}/{bar} with those variables undefined due to a bug in the code above this line. All servers got deleted and the offsite backups too because the remote storage was mounted just before by the same script (that is a backup maintenance script)." The terse "rm -rf" is so famously destructive that it has become a joke within some computing circles, but not to this guy. Can this example finally serve as a textbook example of why you need to make offsite backups that are physically removed from the systems you're archiving?"Rm -rf" would mark the block as empty, and if the programmer hasn't written anything new, he should be able to recover nearly all of the data. Something about the story feels weird.

Comments

insurance fraud at best

[Anonymous Coward]

This has such a smell of BS around it. given the fact that backups are indeed offsite and that a company has more the 1 server etc.etc. Even my own simple setup consisting of a pc, laptop, tablet, qnap and some external HDD and sticks is impossible to delete with 1 script. total bollocks.

Wonder if he found incriminating material or has gambling debts, far more plausible

Old Saying

[Tablizer]

"To err is human. To really fuck things up, you need a computer."

I prefer that any bulk or query-based "delete" command ask for confirmation along with basic feedback. Example pseudo-code:

> delete *:*.*

You are about to delete 832 folders and 28,435 files.
Your choices are:
      1 - Proceed with deletion
      2 - List path details about the above folders and files
      3 - Cancel deletion
Your Choice: __

(end of example)

It may be slower and/or more resource intensive, but that's better than mass boo-boo's.

An optional command parameter could switch off verification, but verification should be the default. This is something Unix/Linux gets backward in my opinion: the default should be confirmation mode, not the other way around. In other words, a command switch should be required to switch off confirmation rather than requiring a command switch to turn confirmation on.

Typical SQL doesn't have a confirmation mode, so I usually do a verification query on the WHERE clause before running the actual:

-- check
SELECT count(*) FROM myTable
WHERE x > 7 AND foo='BAR'

-- actual, keeping same where-clause
DELETE FROM myTable
WHERE x > 7 AND foo='BAR'

I also often inspect at least some of the actual rows, not just the count. Thus, as a rule of thumb, do random spot-checks of actual data, and a total count before final command execution.

Re:Three words

[Triklyn]

... are you suggesting that there's someone out there that knows how to shoot a fireball out of a chopstick?

please elaborate on that

Re:Wasn't he trolling?

[crunchygranola]

My operating theory is that the guy is constructing an alibi. Perhaps he has gotten wind of an investigation and wants to look like a hapless idiot and not someone engaged in destroying evidence.