出大事了！
據可靠消息，位于荷蘭海牙的一家雲主機商 verelox.com， 一名前任管理者删光了該公司所有客戶的資料，并且擦除了大多數伺服器上面的内容，客戶資料恢複希望渺茫。
引用verelox.com公告全文：
首先，我們想要對由此造成的任何不便表示歉意！ 不幸的是，一名前任管理者删光了所有的客戶資料，并且擦除了大多數伺服器上面的内容。正因為如此，我們已采取了必要的步驟或措施，暫時将我們的網絡下線。我們一直在努力恢複資料，但是這個方法可能恢複不了已丢失的所有資料。我們的網絡和托管服務會在本周恢複正常，到時會打上安全更新版。仍對我們的服務有興趣的現有客戶将獲得服務的相應補償。 如果客戶有重要資料，請聯系我們：[email protected]。[email protected]�的資料。 狀态更新1：（最終）位于荷蘭的所有專用伺服器應該會在協調世界時（utc）傍晚6點投入正常運作。我們仍在為雲伺服器制定一套解決方案。 狀态更新2：所有專用伺服器已正常運作。如果您的專用伺服器還是遇到任何問題，請發送電子郵件至[email protected]。眼下，所有虛拟機都上傳到一台新的伺服器。
等等，又是荷蘭？！我怎麼聞到了似曾相識的味道捏。沒錯，年初的gitlab的删庫事件也發生在荷蘭！看來今年不是荷蘭的dba時來運轉的好時期。
回到事件，要怎麼處理呢？我也不知道啊，靜觀其變。
不過這慘絕人寰的事情接連發生，讓多愁善感的小編又要失眠了。月黑風高，有酒有故事，我們一起來回顧下那些删庫跑路的日子吧。
我們一起删庫跑路
不知道什麼時候開始，有一本紅遍大江南北的書叫做《mysql 從删庫到跑路》廣泛流傳于it界，并持續陰魂不散，帶着一股妖風，影響了整個it界的風氣。廣大的運維dba們，大概是找不到女朋友生活沒有什麼樂趣吧（小編已經做好被打死的準備了），非得找點好玩的事情來體驗下人生。什麼最好玩呢，當然是破壞！
來我們玩個遊戲！
問：你想删庫嗎？ dba：我有病啊 dba：不想啊 dba：要負責任嗎？ dba：我操，這麼刺激的事誰不想幹！
看出來了吧，沒有不想删庫的dba，隻有不想負責任删庫的dba。但是自從'從删庫到跑路'這一思想傳遍大江南北，大家都知道了答案，再不濟我還可以跑啊！你是不是也是這麼想的。
大家都想删庫，都想好了出路。果然2017在劫難逃。我們來細數一下2017所遭遇的删庫跑路事件。
斷電又不怪我
遊戲進度回退了，辛辛苦苦掙來的裝備都不見了，然而面對網易和暴雪如此誠懇的态度，想發火都不容易。
深夜加班我也累呀
這估計是春節期間最勁爆的消息了，大過年的大家都放棄了吃肉喝酒的好光陰大半夜守着gitlab的故障分析直播。
講真，我還真沒有見過孩紙們這麼熱愛學習的時候呢。
老闆你總是舍不得買高性能的存儲
instapaper 最初的全文檢索使用一台 sphinx 伺服器直接和 mysql 聯合提供搜尋，這個搜尋使用 aws ec2 大約70gb 記憶體，4tb 存儲的資源： instapaper 的索引資料量（資料庫的資料量未知），在2016年5月時資料量2.2tb，每月增長約110gb，後來實在慢的不行，最後選擇了 aws 的 elasticsearch cluster來承載這項服務。而最終，還是敗在了存儲，資料寫入失敗直接導緻資料庫當機。
别這麼看我，我們都犯錯，隻是我犯的錯誤更嚴重罷了
手動删庫簡直太low，我都是腳本自動删
一個 google music 使用者彙報某些之前播放正常的歌曲現在無法播放了。google music 的使用者支援團隊通知了工程師團隊，這個問題被歸類為流媒體播放問題進行調查。3 月 7 日，負責調查此事的工程師發現無法播放的歌曲的中繼資料中缺少了一個針對具體音頻資料檔案的指針，于是他就修複了這個歌曲的問題。 但是，google 工程師經常喜歡深究問題，也引以為豪，于是他就繼續在系統中查找可能存在的問題，當發現資料完整性損壞的真正原因時，他卻差點吓出心髒病:這段資料是被某個保護隐私目的的資料删除流水線所删掉的。google music 的這個子系統的設計目标之一就是在盡可能短的時間内删除海量音頻資料。 該流水線任務大概誤删除了 60 萬條音頻檔案，大概影響了 2.1 萬使用者.
辦法不早就教你了嗎
網際網路發展仍是日新月異，挑戰無處不在。要想變挑戰為機遇，隻有創新和技術才有可能。隻有重視技術的公司，才能充分發揮技術人員的能動性，也将更容易在技術的競争中勝出。 我們經常開玩笑，很多公司，做不到技術驅動，因為他的每一步都是上司提出上司拍闆，它隻能叫上司驅動。而如果一個公司在遇到事情之後就總是想到懲罰，不注意保護和發揮技術人員的能動性，技術導向也隻能是一個口号。
是以下次呢，如果你手抖删庫了，一定要冷靜地到你老闆那裡說，人家也很傷心，需要抱抱安慰。
好吧你這樣就太過了，會被老闆轟出去的。但你要記得，不要談故障的原因，要談解決方案，be a man,你自己闖下的禍，自己承擔起來!
萬一老闆真要懲罰你怎麼辦，一個字，跑啊！說實話，你是不是老早就打算删庫跑路了，隻是一直沒有機會。
小編最近查了一下，發現想跑路的人真是不少。
我說大家都怎麼了呢，這是跟世界有多大的仇恨呀。不過考慮到，你們可能真的沒有遇到好老闆心裡苦，你看像我這種生活在幸福深處的員工，有一個超級完美的老闆，就完全不能了解你們普通人的心情。
既然你都有了這種想法，我好像也沒有什麼可說的了。但是我必須要再次苦口婆心地提醒你，備份重于一切！rm是危險的！三思而後行！如果這三句話還沒有成為你的座右銘，我覺得你應該需要休個假好好思考一下人生了~
最後，小編實在沒實力，得找老闆來撐下場子。壓軸出場，如何幸存于類似事故？
好吧，我們談一談如何避免陷入這樣的困境？以下是我們的一些思路，與大家商榷。 首先，要有完善、有效的備份和容災機制。誠然很多企業都有了一整套的備份、容災機制，但是這套備份機制能否真實奏效是需要檢驗的。我接觸過某大型企業，投入巨資興建的災備中心，從未正式切換過，這樣的災備在故障來臨時也很難有人拍闆去進行切換，是以備份的有效、容災手段的有效是必須確定的。注意，備份的恢複速度必須足夠的考慮到，錄音帶的低效備份關鍵時刻會害死人。 其次，要有完善的故障處理政策和流程。對于不同系統，在關鍵時刻要優先確定什麼，是要訂立規則的，有了規則才能照章辦事，不走錯方向，不無辜背鍋。幾年前某國内金融系統出現資料壞塊，同樣選擇了帶病修複，最終沒能解決問題，同樣選擇了回檔承擔了資料損失。 再次，要有端到端融會貫通的應急機制。也就是說不僅僅技術上具備容災應急的響應方案，從業務端同樣要有對應的預案，以便應急時同步處理，差別對待。很多時候，有了業務上的應急、降級服務方案，技術層面的處理就能夠從容許多。 最後，要有能夠快速協同的團隊資源。很多時候嚴重的故障，需要較大規模的專業團隊協作處理，原廠商和第三方在其中都承載着重要的角色，是以關鍵時刻，要能夠獲得内外部快速及時的支援，尤其是在綿延數天的高強度工作中。
講真，不要把我們的話當成耳旁風，備份重于一切。預防和檢測少不了。
如果真的删庫了，請找雲和恩墨，我們7*24為你的資料庫安全站崗。