When Deleting Databases Becomes Revenge: Real‑World Cases and What You Must Do
This article recounts several real incidents where disgruntled engineers or admins deleted critical databases as retaliation, highlighting the severe consequences and stressing that proper backups and cautious use of destructive commands are essential for any organization.
Deleting a database is easy, but escaping the consequences is hard; a popular joke says a DBA who never dropped a database leads an incomplete life, yet when dropping becomes a tool for revenge, no one can outrun the law.
Programmers angry about being fired, delete the database and run away – Italian company Venida Computer Data Software suffered a breach where a former programmer repeatedly accessed and deleted database records and software products before being arrested.
Months earlier, Italian police received reports that the company's databases were frequently hacked and large amounts of data were maliciously deleted, suspecting an insider.
The suspect, a 45‑year‑old former software engineer, admitted to using his former server privileges and network vulnerabilities to log into the database, denying data theft but confirming deletion as retaliation.
In September 2018, a Shunfeng engineer mistakenly deleted an online system database and fled; the error caused a temporary insurance dispatch function to be unavailable for about 590 minutes, leading to his dismissal.
In September 2017, an IT engineer at a major company formatted HSS equipment during a capacity expansion for Guangxi Mobile, erasing data of nearly 800,000 users.
In February 2017, a GitLab system administrator, after mitigating a DDoS attack, mistakenly executed a directory‑deletion command on the production environment, reducing 300 GB of data to 4.5 GB and forcing GitLab offline. sudo rm -rf In April 2018, VPS provider Kuriko lost all host data after a data‑center technician ran rm -rf /* on the server.
In June 2017, a former administrator at Dutch host Verelox deleted all customer data and most server contents, causing the service to go offline with data likely unrecoverable.
These cases serve as a stark reminder: backups are paramount , rm is dangerous , and every action should be considered carefully because the fallout from a deleted database can be catastrophic.
Sources: China News Service, Programmer Headlines, ChinaUnix
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
21CTO
21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.