免费咨询申请
24小时全国咨询热线：0755-83775551
九月中旬，东莞长安一家精密五金加工企业把 ERP 服务器送到了我们深圳的实验室。企业规模不大，一百多号人，但订单、出入库、对账全部跑在这套系统上。IT 主管说，ERP 已经停了两天，再不恢复，月底的账没法结。
事情的起因并不复杂。运维人员在生产库上执行了一条删除语句，删掉的是一张中间表，本来想着重建就行。但这条语句触发了一连串连锁反应：ERP 的定时任务在半小时后启动，把空表的数据同步到了订单主表和明细表，等第二天业务员发现单据全是空白时，数据库已经又写入了将近两天的业务数据。
他们做的第一件事是还原最近的备份。备份策略是每周日做一次全量备份，最近的一次在六天前，也就是说，就算备份能用，中间六天的数据也回不来。更麻烦的是，这台服务器上的数据库一直跑在简单恢复模式下，没有事务日志备份，误删的记录没有留下任何可以前滚的日志。
收到服务器后，第一步不是直接去恢复文件，而是对两块硬盘做完整的只读镜像，之后所有操作都在镜像上进行。这样做有两个目的：一是防止操作破坏现场，二是把硬盘物理层的坏道、固件问题先隔离出来。
接着检查数据库文件的内部结构。MDF 文件的页头、分配页、系统表都完好，说明数据库本身没有物理损坏，问题出在业务表的记录已经不在页里。我们进一步做两件事：一是解析日志文件，确认误删操作的时间点以及后续写入的范围；二是对数据库文件的未分配空间做页级扫描，找出被标记为已释放、但数据实际还留在盘上的记录页。
检查到这一步，情况比预想的好一些。定时任务覆盖写入时并没有把原来的数据页全部填满，订单明细表的记录页大约有七成还完整保存在未分配区域里，出入库表的情况差一些，只有五成左右。
方案分三层做。第一层，把六天前的全量备份还原到一台测试服务器上，作为基础数据。第二层，从镜像的未分配空间中提取仍可识别的记录页，按页头和行结构重组成数据行，再按主键、外键关系回填进基础库。第三层，处理被覆盖得最厉害的对账表，这部分改用相邻页的残片做特征匹配，结合 ERP 自身的流水号规则和单据编号连续性做校验，把能确定归属的记录补回。
整个过程最花时间的不是技术，而是校验。ERP 的数据之间关联很强，一张订单少了明细，账就不平。我们和客户的财务、仓库各抽了一个人，在测试库里逐条对账，遇到差异就回到原始镜像查依据，确认无误后才写入正式库。
三天后交付，订单、出入库、对账数据基本全部找回，只缺了不到两个小时的窗口数据，那段时间刚好是下班后，没有新的业务单据产生，客户确认可以接受。系统上线第二天正常开单。
事后我们给这家企业提了两条建议。第一，数据库从简单恢复模式改成完整恢复模式，并加上每十五分钟一次的日志备份，以后再遇到误删，恢复窗口可以精确到分钟。第二，备份不要和数据库放在同一台物理服务器上，也不要只留一份本地副本，否则机器一旦出问题，备份和数据会一起失去。
数据库数据丢失的原因里，硬件故障只是一部分，更多是误删、误覆盖、备份不可用这类操作层面的问题。这类故障能不能救回来，取决于发现得早不早、现场保护得好不好。深圳市补天时代科技有限公司专注数据恢复二十余年，RAID 阵列、服务器、数据库、硬盘开盘各类故障都有对应的恢复工艺，检测免费，方案和报价先出再决定做不做。有数据库数据丢失的情况，可以直接把服务器现状说清楚，电话 0755-83775551，地址：深圳市福田区华强北深南中路2070号电子科技大厦A座35楼。
