下廚房6月26日數據丟失事故總結
在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移位至大值前，半天創建的內容和原位置內容的衝突，我們還在盡力修補。
以下是當前主要內容的恢復情況：
| 菜譜 | 收藏 | 贊 | 作品 | 關注 | 菜單 | 用戶 | |
| 恢複比例 | 99.0% | 98.6% | 99.2% | 99.5% | 99.5% | 99.3% | 99.1% |
五. 致謝
特別感謝一下三個公司和個人在這7天的恢復工作中對我們的幫助。
杭州沃趣網絡科技有限公司(@沃趣科技)是來自原阿里巴巴DBA/SA團隊核心骨幹組建的創業公司，提供數據庫和系統相關的專業服務和產品，陳棟（@grassbell）、李春（@pickup112）對破損的數據庫文件進行了災難修復，提取出絕大部分數據表的內容。
周振興（@orczhou）是淘寶MySQL數據庫運維負責人，他對破損文件中部分帶二進制段的數據表進行了修復，提取到了相關內容。
北亞數據恢復中心是來自前信息產業部職鑑中心，專門從事數據恢復服務的技術公司。張宇，劉子龍對硬盤文件進行了完整的恢復，使我們得到了數據庫的全部數據。