有個客戶是一個跨國公司的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管理和維護人員，災備方案和資料操作監控需考慮全面 ，不能災備發生時，再考慮處理模式。