那天凌晨三点，我接到一个客户的电话，声音都在发抖。他们公司的ERP系统数据库被人加密了，所有表都变成了乱码，后缀名改成了.locked。更糟的是，他们刚做完的月度备份，居然也中了招——因为备份服务器和数据库服务器在同一个网段，勒索病毒顺着共享目录全给加密了。这种情况我见过太多次了，每次看到客户急得团团转，我都想说：SQL数据库中毒了，先别慌，乱操作才是最大的风险。
很多人一发现数据库中毒，第一反应就是重装系统或者直接格式化硬盘。这恰恰是最要命的做法。SQL Server的MDF文件即使被加密，文件头信息往往还残留着部分原始数据，某些情况下甚至可以通过专业工具恢复出未加密的碎片。你一旦格式化，这些残存的数据就彻底没了。我见过一个做外贸的老板，为了省事把服务器重装了，结果价值几百万的订单数据全变成了空白，后来找了三家数据恢复公司都没戏。所以第一步，也是最重要的一步：立即断网，然后对整块硬盘做镜像备份。别管是Ghost还是dd命令，先把原始数据完整复制一份出来，然后再在这个副本上做恢复操作。
断网这个动作听着简单，但很多人操作不规范。不要只断外网，内网也要断。勒索病毒往往通过内网横向传播，你留着内网连接，其他服务器也可能被感染。正确的做法是直接拔网线，然后关掉交换机上对应端口。如果是云服务器，就在控制台里把安全组规则清空。做完这些，再检查一下有没有其他机器出现异常进程——SQL Server的sqlservr.exe进程下如果多了奇怪的dll注入，说明病毒可能还在内存里活动。
接着进入第二步：找备份。这里有个残酷的现实，大多数企业的备份策略都是不合格的。我接触过上百个中毒案例，真正能靠备份完整恢复的不到三成。不是备份文件本身被加密了，就是备份计划只覆盖了数据库文件，没覆盖系统库。SQL Server的msdb库里有作业历史、维护计划信息，master库里有登录名和服务器配置，这些不备份，恢复后也是残缺的。所以如果你有备份，先检查备份文件的完整性——用RESTORE VERIFYONLY FROM DISK命令验证一下，别急着恢复，先确认备份本身没坏。
如果你连备份都没有，那就要用到第三步：尝试日志恢复或者第三方工具。SQL Server的日志文件（LDF）记录了所有事务操作，即使数据文件被加密了，日志文件里可能还存着未加密的完整页面。你可以尝试把数据库设置为紧急模式，然后用DBCC LOGINFO看看日志里还有多少可用空间。如果日志文件没被加密，有机会通过日志挖掘工具重建出最近一段时间的数据。这个方法成功率不算高，但值得一试。另外，市面上有些数据恢复软件声称能扫描MDF文件碎片，但你要有心理准备——这些工具对连续存储的页面有效，对碎片严重的数据库基本无能为力。
说到第三方工具，我得提醒一句：别病急乱投医。很多人中毒后上网搜恢复工具，下载了一堆来路不明的软件，结果不但没恢复数据，反而让情况更糟。有些工具本身就是病毒伪装，或者恢复过程中会覆盖原始数据。我认识一个做数据库运维的朋友，客户中毒后拿了一堆免费工具轮流试，把原本可能恢复的日志文件也搞坏了。真要用工具，认准正规厂商的试用版，或者找专业的数据恢复公司远程操作，别自己瞎折腾。
恢复完成后，很多人觉得万事大吉，其实这才是真正的开始。你要做的不只是把数据找回来，还要堵住病毒入侵的漏洞。检查一下SQL Server的登录账号，看看有没有异常的高权限用户——很多勒索病毒是通过SQL注入拿到sysadmin权限后直接上传恶意代码的。改掉所有弱密码，尤其是sa账号，别再用123456这种密码了。关闭不必要的端口，比如1433端口不要直接暴露在公网上，用VPN或者堡垒机来访问数据库。
还有一件事容易被忽略：漏洞扫描。恢复之后用工具扫一遍系统，看看有没有已知漏洞没补上。SQL Server的补丁要打全，操作系统也一样。很多中毒案例都是因为服务器几个月没打补丁，被攻击者利用已知漏洞进来的。你的防火墙、杀毒软件、入侵检测系统，该更新的都更新一遍，别把钱省在这上面。
说句掏心窝的话：数据恢复是一道防线，永远比不上未雨绸缪。这次救回来了是运气好，但运气不会每次都在。建立完善的备份机制——每天全备、每小时日志备份、异地容灾，这些投入远比中毒后找恢复公司便宜得多。SQL数据库中毒确实吓人，但记住这三步：断网锁盘做镜像，验证备份再恢复，补漏堵洞防再犯。慌解决不了问题，冷静按步骤操作，大部分数据都还有救。我见过太多人在关键时刻因为乱了阵脚，把原本能救回的数据彻底搞丢了，那才是最让人惋惜的。
