.devos 勒索病毒加密数据库恢复
.devos 加密后会在文件名尾部追加家族标识，并改写文件头部字节。数据库文件被加密后无法附加，但加密范围往往小于整文件，先判断覆盖范围再决定路径，是这类故障处置的第一原则。
如何确认是 .devos
三个可观察特征，按可靠性从高到低：
- 扩展名。文件名尾部被追加 .devos，如 db.mdf 变为 db.mdf.devos。注意扩展名可以被伪造，不能单独作为判断依据。
- 勒索信内容。目录下生成的说明文件里通常会自报家族名与谈判入口，这是最直接的证据。
- 加密文件的内容特征。用十六进制查看器看文件尾部，部分家族会在末尾写入标识串。
家族判定影响的是「有没有现成解密工具」这一判断，不影响恢复流程本身——无论哪个家族，走的技术路径大同小异。
第一步：确定加密覆盖范围
这一步决定后面是「几小时能解决」还是「要按周算」。打开文件逐段检查：
- 头部若干 KB 被改写、中段可识别出数据库页结构：部分加密，数据主体还在，走页级提取。
- 整文件高熵：完全加密，转向查找备份、卷影副本、磁盘残留的旧文件。
- 只有扩展名变了、内容未变：改名型伪装或加密中断，把扩展名改回后可能直接可附加——这是最幸运的一种。
本例的 ERP 数据库属于第一种，加密推进到一半被中断，数据区保留了大段完整页。
第二步：为什么加密会「中断」
常见的三种中断原因：加密进程被安全软件终止、服务器在加密过程中断电或重启、磁盘空间不足导致写入失败。
中断对恢复是好事——它意味着文件只被部分覆写。但同时带来一个问题：文件的哪一段被加密、哪一段完好，没有规律。所以必须逐段扫描，不能假设「前半坏后半好」。
第三步：页级提取的实际操作
定位页。SQL Server 的数据页大小固定（通常 8KB），页头字段有稳定的取值特征，可以在字节流中滑动扫描定位每页起点。
归类。根据页头中的对象 ID 把页分派到具体表；无主的页先放入待定区，后续按行数据特征尝试匹配。
还原结构。从 sys.objects、sys.columns 的残留页读取表名与字段定义。系统表若损坏，则依据行数据的字段边界反推——这一步最费人工，也是工期不可控的主因。
提取与重建。按槽位数组解析每行，落到中间表，再在干净实例上建库导入。导入时先禁用外键约束，完成后再启用并校验。
第四步：ERP 库特有的校验重点
ERP 类数据库的恢复难点从来不是「把数据读出来」，而是「读出来之后业务能对得上」。三项必查：
- 物料收发存平衡。按物料汇总期初 + 入库 − 出库，是否等于期末。不平说明流水表有页缺失。
- 往来账龄可核。应收应付的余额能否按单据逐笔展开，总额是否与总账一致。
- 单据关联完整。采购单 → 入库单 → 应付单的链路是否连续，断链说明中间某张表的页未提取到。
这三项都过了，才能说「恢复完成」。只验证库能打开、表能查询，是把风险留给业务部门。
复盘：这次真正起作用的三件事
第一，现场没有被反复折腾。企业 IT 在发现异常后停止重启、没有再尝试附加，避免了二次写入。
第二，加密过程本身中断了。这是运气成分，但也说明及时断网、切断加密进程的网络依赖是有意义的。
第三，镜像做得早。所有分析都在副本上反复试，原盘始终是干净的。
反过来，如果这台机器有物理隔离的每日备份，本次处置只需数小时。这也是我们给所有制造业客户的同一句话：先解决备份，再谈恢复能力。
常见问题
把 .devos 扩展名改回去就能用吗
只有当文件内容根本没被改写时才有效——也就是加密中断在早期、只完成了改名。绝大多数情况下内容已被覆写，改回扩展名后文件依然无法打开。判断方法是看文件头的字节内容，而不是看扩展名。
数据库被加密，同机的备份文件也被加密了怎么办
转向三个方向：磁盘上被删除但未覆写的旧备份、卷影副本残留、异地或云端备份。三者都没有时，只能走页级提取，且恢复目标要现实一些。
怎么避免下次再中招
三件事优先级最高：备份物理隔离（离线或不可变存储）、关闭不必要的端口与共享、给数据库服务账号最小权限。这三项做到位，能挡掉绝大多数同类事件。