我干了十来年数据库运维，见过太多公司栽在勒索病毒手里。上周有个做跨境电商的兄弟半夜给我打电话，声音都抖了——SQL Server里200多 GB 的订单数据全被加密，后缀变成了 .locked。更惨的是，他们的备份文件也连坐遭殃，因为备份盘一直挂在服务器上没断开。这种事见得多，但每次听到还是揪心。今天我就把 SQL 数据库中勒索病毒后的修复流程掰开揉碎讲清楚。
先说第一步，断网，必须是物理级别的断网。很多人中毒后第一反应是跑去查日志、杀病毒，这是最蠢的操作。勒索病毒通常有横向扩散能力，你查日志的功夫，它可能已经顺着网络跳到其他服务器上。正确做法是直接拔网线，或者关闭交换机对应的端口。然后检查数据库文件——看看 .mdf 和 .ldf 后缀有没有被改，桌面上是否出现勒索信。如果是 MSSQL，通常会出现扩展事件被挂起，数据库状态变成“可疑”或“恢复挂起”。这时候千万别重启数据库服务，重启会让病毒进程有机会写入脏数据。
第二步找备份，但别急着恢复。很多人发现备份文件也被加密就慌了，其实还有救。比如，备份文件如果放在独立的 NAS 或者磁带库里，只要物理隔离做得好，大概率是干净的。再比如，有些公司使用云备份，如阿里云 RDS 或 AWS 的自动快照，这些不受本地勒索影响。最坏的情况是本地备份也被加密，那就要看加密方式。如果是弱加密算法，比如使用 AES‑128 且密钥生成有漏洞的，可能通过分析勒索信中的邮箱或钱包地址，在公开的解密工具库里找到对应解密器。NoMoreRansom 项目收录了上百种解密工具，值得一试。
第三步是恢复数据，这里门道最多。如果找到了干净的备份，恢复流程不是直接还原数据库，必须先清理环境。把中毒服务器格式化、重装系统，这是必须的。有些人图省事，只删了病毒文件就恢复备份，结果病毒残留进程被激活，等于白忙活。重装完后，安装同版本的 SQL Server，注意打上最新补丁，因为很多勒索病毒就是通过旧版漏洞进入的。然后恢复数据库，但别急着连业务。先跑一遍 DBCC CHECKDB 检查完整性，再测试几条关键查询，确认没有问题后再上线。
讲个真实案例。去年一家制造企业中了 GlobeImposter 勒索病毒，他们的 MSSQL 备份文件虽然被加密，但幸运的是备份存放在一台 Linux 服务器上，勒索病毒没有感染 Linux 系统。他们用了三天时间，从备份里提取出完整数据，损失只有当天的订单记录。但另一家就没这么好运，备份盘一直在线，病毒直接加密了所有历史备份。他们只能找数据恢复公司，花了 15 万才抢救回 70% 的数据。所以备份必须遵循 3‑2‑1 原则：三份副本、两种介质、一份离线。
再说说修复过程中的技术细节。如果数据库状态显示“恢复挂起”，别急着执行 RESTORE 命令。先用以下命令检查日志文件头：DBCC LOGINFO。如果日志文件也被加密，可能会显示文件头损坏。这时可以尝试重建日志文件，语法是但该方法只适用于数据库本身没有被严重破坏的情况。如果 .mdf 文件已经被加密，那只能靠备份或解密工具了。
很多人问能不能通过修改文件后缀来恢复，比如把 .locked 改成 .mdf 直接附加。这个想法很危险。勒索病毒不是简单改后缀，而是对文件内容进行了加密，改后缀只会让 SQL Server 读取到乱码数据，导致服务崩溃。正确做法是先用十六进制编辑器查看文件头，看看 MSSQL 的标识符 0x0100 是否被替换。如果被替换，说明文件已加密，必须使用解密工具或从备份恢复。
说防。修复完别以为就完事了，还得查清病毒是怎么进来的。常见入口有：SQL Server 的 sa 账号弱密码、RDP 远程桌面爆破、钓鱼邮件附件。我见过最离谱的案例，某公司把 SQL Server 的 1433 端口直接暴露在公网上，sa 密码设成 123456，这基本就是给勒索病毒送菜。修复后必须做三件事：更改所有数据库账号密码、开启 SQL Server 的审计日志、关闭不必要的端口。最好再装一个扩展事件监控，对可疑的批量查询或权限变更做实时告警。
SQL 数据库被勒索病毒搞了，别慌，按“断网、找备份、恢复数据”这三步走。但说再多，防比治重要得多。备份要离线，补丁要及时，密码要复杂。别等数据没了才后悔。
