当大量SharePoint文档被删除且回收站无记录时，IT管理员面临重大挑战。通过排查服务器审计日志和SQL数据库，可以确定删除者。在SQL的EventCache表中，找到特定Library ID和event type 16388来追踪删除操作。为恢复数据，建议在UAT环境还原备份数据库，同步丢失文档至生产环境，避免数据丢失。对于此类事件，强调灾备计划和监控的重要性。
有个客户是一个跨国公司的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，如下图所示：
最低0.47元/天 解锁文章
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
