在6月26日凌晨12點左右，我們在做線上數據庫的備庫時，誤將線上數據庫分區上的所有文件刪除。丟失的數據時間段為4月23日至6月25日兩個月，在經過7天的努力后，恢復了99%以上的數據。（具體見下面的統計）。

下面把整個事故過程記錄下來，令關心本次技術事故的人們知曉。

一. 事故隱患

現在回顧，事故隱患在4月23日之后就已經存在。

我們線上數據庫使用的是MySQL，在4月23日之前，我們對線上數據庫主節點有三類備份。一是有一個獨立的數據庫從節點來備份，與線上服務器保持數據的實時同步，需要時可切換作線上使用。二是會定期把整個數據庫dump成sql文件來備份，一天保存一次，備份的來源是數據庫從節點。三是主節點開啟有binlog，默認是保存十天的日志，十天內有任何事故可以從日志里完整恢復全部數據。這三個備份分別存放在兩臺不同的物理機，三個不同的分區上，是當時想到的最安全的方式。

4月23日，我們把數據庫主節點遷移到一臺新的物理機上，并把版本升級到5.5。由于版本和配置的問題，原來的從節點并不能直接使用。而一天一次的備份來源是從節點（備份主節點會令網站和手機app有1小時左右的卡頓），這個備份方式也就停止了更新。只有最后一個binlog還在運行。數據庫遷移之后應用服務器存在一些性能問題需要投入時間，包括修復MySQL5.5版本和原代碼的兼容，以及把應用服務器從gunicorn換成uwsgi，之后又陸續有一些開發任務，以致重新啟用備份節點的工作一再拖延。

我們對數據庫遷移工作的管理存在失誤，是造成事故的根本原因。沒有完成數據庫備份節點，遷移工作就并沒有結束。我們技術團隊的所有人對這個事故都負有責任，這個隱患在兩個月里都可能被發現，每個人都有可能提出這個工作的高優先級。也都可能提出相應的彌補工作來保證數據安全，比如在啟用從節點前延長二進制日志的保存時間等。是我們的工作失誤使數據庫成為系統最脆弱的環節，經受不住偶然事故的沖擊。

二. 事故發生過程

6月26日凌晨12點左右，我們開始重新建立備份節點的工作，需要把原來的從節點刪除，重新安裝，所以先使用了rm -f方式刪除備份節點分區上的所有文件。

5分鐘后，發現剛才刪除的是數據庫主節點的分區，為防止硬盤繼續寫入，就馬上把mysql進程停止了。所有技術人員開始應急處理。一是把整個分區dd成鏡像，準備做將來硬盤恢復的備份。二是把memcache里的數據dump出來，以備可能的恢復。三是重新啟用原來的從數據庫，由于數據時間只到4月23日，需要調整近兩月表結構變更，讓最新的代碼可以跑起來。

當天的應急工作至凌晨4點，服務器都恢復訪問，但數據停留在4月23日。

在整個應急過程中，部分是緊張，部分是溝通上存在誤解，還是出現了失誤。當配置從數據庫的技術人員完成之后，重啟了服務器和memcache，恢復了正常訪問。但是做memcache導出工作的技術人員還沒有完成，所以最終能從memcache里得到的那部分數據只有一半左右。

事后從沃趣科技的數據庫工程師那里得知，我們第一時間停止MySQL防止硬盤繼續寫入這個應急措施是錯誤的，即使分區完全沒有文件，mysql的進程繼續運行，只要保留這個現場，可以從內存中獲取更多的數據庫結構信息，對恢復數據非常有幫助。

三. 事故后恢復工作

事故后恢復工作從數據來源分為4條線索進行：

1. 硬盤上數據的恢復（主線）

2. 從memcache導出的數據恢復

3. 從binlog里恢復

4. 從搜索引擎的快照里恢復頁面

以下按時間詳細敘述：

• 6月26日8點，我們去機房把服務器硬盤取出來，送到了一家硬盤數據恢復公司。到下午5點左右恢復出ibdata1文件，文件可能破損。
• 6月26日12點，為了預防新插入的內容和原內容的沖突，我們把所有表的id都加到一個大值，半天的內容隨后做特殊處理。
• 6月26日23點，導入完了所有memcache里的數據。
• 6月27日上午，從硬盤里又恢復出部分.ibd文件，也包含部分數據信息。已確定包含數據的ibdata1和.ibd文件有破損，無法直接使用，只能嘗試從破損文件中提取部分有效信息。
• 6月27日下午，聯系上杭州沃趣網絡科技有限公司的陳棟、李春，開始對數據的提取工作。至凌晨1點，提取出.ibd文件的數據，恢復部分表。
• 6月28日全天，沃趣科技開始對ibdata1文件的提取，至29日凌晨1點，他們已經提出大部分數據。
• 6月28日下午，得到阿里巴巴集團的周振興的友情支持，他開始幫忙做ibdata1文件的提取工作，至凌晨4點，他完成部分帶二進制段的數據表的修復，提取到了相關內容。
• 6月28日下午，我們聯系上北亞數據恢復中心，開始再次嘗試對硬盤文件的恢復。
• 6月28日晚，我們把所有從binlog來的數據導入完，完整恢復了最后10天的數據。
• 6月29日中午，從沃趣科技得到的優先級較高的數據表已經恢復完成，開始恢復次優先級的數據。
• 6月30日中午，提取完所有能從6月27日獲取的破損數據庫文件里的所有內容。至此這一階段提取到缺失總數據量的近70%。
• 6月30日下午，開始從搜索引擎快照里抓取部分菜譜重要頁面，修補缺失的內容。并聯系上某搜索引擎的快照部門，希望獲取我們網站的全部頁面快照。
• 7月1日上午，北亞數據恢復中心取得很大的進展，提取到幾乎是完整的ibdata1文件，至下午6點，提取到除了收藏和贊的所有數據表，我們開始把數據導入，至凌晨4點，恢復完得到的所有數據。
• 7月2日整天，由于導入的舊數據和新注冊的用戶存在部分數據不一致，我們盡力配合用戶恢復。
• 7月2日下午4點，北亞提取到ibdata1剩下的文件碎片，得到了完整的ibdata1文件，mysql無報錯啟動，我們得到了6月26日凌晨事故前的完整數據庫。至凌晨2點，我們提取出剩下的收藏和贊，恢復到數據庫里。至此損失的數據內容已經恢復到99%。

下一階段：

• 在丟失兩個月數據的這一周時間里，用戶新產生的數據和恢復的舊數據會有少量不兼容的情況，我們會全力幫助用戶找回自己的全部數據，出現的錯誤敬請用戶包涵，幫助我們走過這一過渡階段。
• 除了原先的三種備份方式外，我們會繼續落實和第三方的云存儲方案的合作，把數據備份到我們的服務器之外的地方。

四. 所缺失的近兩月數據當前的恢復情況

至今，內容大多得到了99%左右的恢復。缺失部分并不是來自硬盤數據丟失，而是6月26日12點前id移位至大值前，半天創建的內容和原位置內容的沖突，我們還在盡力修補。

以下是當前主要內容的恢復情況：

五. 致謝 

特別感謝一下三個公司和個人在這7天的恢復工作中對我們的幫助。

杭州沃趣網絡科技有限公司(@沃趣科技)是來自原阿里巴巴DBA/SA團隊核心骨干組建的創業公司，提供數據庫和系統相關的專業服務和產品，陳棟（@grassbell）、李春（@pickup112）對破損的數據庫文件進行了災難修復，提取出絕大部分數據表的內容。

周振興（@orczhou）是淘寶MySQL數據庫運維負責人，他對破損文件中部分帶二進制段的數據表進行了修復，提取到了相關內容。

北亞數據恢復中心是來自前信息產業部職鑒中心，專門從事數據恢復服務的技術公司。張宇，劉子龍對硬盤文件進行了完整的恢復，使我們得到了數據庫的全部數據。