有個客戶是一個跨國公司的SharePoint IT管理人員，前段時間的某一天接到很多end user的投訴：批量的documents被人刪除，並且Site Collection的recycle bin中沒有任何刪除記錄，如大家所知，數據對一個企業來說是寶貴的財富，一旦數據丟失必然是Critical Issue.
該客戶接到批量的end user投訴後，從週五到下一個週一利用3天時間晝夜排查SharePoint每一個Web front end Server的auditor log，太多log文件無法排查具體的刪除動作是誰？
後來該客戶與我聯繫後，瞭解了全部背景後，迫在眉睫的有2個問題需要解決：
- 需要查出誰誤刪除了大量的文檔，同時要給領導彙報重大事件的Report和日後的事件如何避免的方案。
- 在SLA規定的範圍內，儘快將丟失的文檔恢復到原來的位置。
客觀講，文檔被刪除後，在SQL的EventCache裏是有document的changelog記錄的，如果客戶能說服SQL Team執行SQL query是可以查詢到誰做了操作。
具體的操作如下：
1.在alldocs表中檢索丟失數據所在的Library ID，如下圖所示：
2.在Eventcache表中，查詢對應library id中的item的event type和modify by，如下圖所示：eventtype=16388，就意味着是'A list item is deleted' + 'A generic delete event'的組合事件說明文檔被刪除，可以通過https://sebmatthews.net/microsoft/from-the-database-sharepoint-eventcache-eventtype-codes/ 查詢對應的event type所表示的含義，modify by的column顯示的account就是刪除文檔的具體用戶。
在查找用戶刪除Document之後，如何恢復丟失的數據也需要謹慎操作的，如果用戶沒有針對Granular進行數據備份，而是採用Database級別備份的話，那麼上一個備份的數據距離當前時間產生的新數據會因爲整個DB級別的還原而丟失，考慮這一點我推薦的方案：把備份DB還原到UAT環境中，找到丟失documents的library，採用sync的方式同步到生產環境對應的位置。
事件反思：作爲資深的IT管理和維護人員，災備方案和數據操作監控需考慮全面 ，不能災備發生時，再考慮處理模式。