被加密的用友服务器上，几乎所有东西都不要删——尤其是那些已经打不开、已经被追加了奇怪后缀、看上去"没用了"的文件。它们恰恰是后面能不能把账套捞回来的全部本钱。
现实中造成不可逆损失的，往往不是病毒本身，而是中招后头几个小时里的清理动作：删掉打不开的 mdf 腾空间、重装系统准备重新上线、在原盘上反复尝试附加损坏的数据库、用来路不明的"修复工具"覆盖原文件。病毒加密是部分破坏，这些操作是彻底覆盖。
先做的事：保住现状，而不是急着修
在讨论留哪些文件之前，有三件事排在前面：
- 把服务器从网络上摘下来（拔网线或在交换机侧隔离），防止加密继续扩散到共享盘、其他服务器和备份机。
- 不要急着重启、重装、格式化。是否关机要看情况：如果能确认加密进程仍在运行且无法通过隔离阻止它继续写盘，停机是止损；如果加密已经结束、系统又承载着取证所需的内存与日志，粗暴断电反而丢信息。拿不准时，优先断网 + 停掉 SQL Server 服务，不动磁盘。
- 在动任何数据之前，先把受影响的磁盘做一份只读镜像或离线冷拷贝。后面所有尝试都在副本上做，原盘封存。这一条比下面任何一条清单都重要。
必须保留的六类文件
用友 U8、畅捷通 T+ 这类产品底层多数跑在 Microsoft SQL Server 上（NC 等产品线也可能用 Oracle，目录结构和文件名会不一样，以你实际环境为准）。下面按价值排序。
1. 账套数据文件：.mdf 和 .ndf
这是核心。U8 默认的账套库名通常形如 UFDATA_账套号_年度，对应 .mdf 主数据文件，大库还可能有 .ndf 次要文件。
即使文件已经被追加勒索后缀、文件头损坏、SQL Server 完全无法附加，也不要删。 很多勒索家族对大文件并不做全量加密，而是只加密头部若干 MB，或者按固定间隔跳跃式加密部分数据块。一个几十 GB 的账套库，被实际破坏的可能只是一小部分，剩下的数据页、索引结构仍然在盘上。专业恢复的做法是绕过 SQL Server 引擎，直接按页签名扫描并重组记录，把凭证、科目、往来、存货这些表的数据提取出来。文件一删，这条路就没了。
2. 事务日志文件：.ldf
很多人觉得日志文件没价值，删起来最不心疼。但 .ldf 记录的是近期事务链，在数据文件局部损坏、或者需要用旧备份 + 增量变动拼接时，没被完全破坏的日志扇区能提供关键的事务回溯依据。保留成本很低，丢了可能就少一截最近的数据。
3. 用友系统库：UFSystem.mdf / UFSystem.ldf
这个最容易被忽略，也最容易在重装时被覆盖掉。
账套数据本身只是数据表，账套编号、启用年度、模块配置、操作员和权限这些元数据全在系统库里。如果只抢救回了 UFDATA 库而系统库没了，恢复出来的数据需要重新建账套、重新做映射、重新配权限，工作量和出错概率都会明显上升。连同用友安装目录下的配置文件一起留着。
4. 所有历史备份：.bak 与账套导出包
无论新旧，无论是否已经被加密，全部保留。
- 没被加密的旧备份：哪怕是三个月前的，它也是一个结构完好的"参照样本"。底层提取工具可以拿它做表结构基准，去比对、解析受损文件里较新的数据。
- 已被加密的 .bak：也别删。备份文件的内部结构有时比被强行杀掉进程的运行态 mdf 更规整，碎片重组反而更顺。
同时翻一翻这些位置：D 盘的自动备份目录、财务个人电脑上手工导出的账套包、移动硬盘、NAS、还没被覆盖的云盘历史版本。真正把损失拉回来的，常常是某个被遗忘的旧备份加上一段增量提取。
5. 勒索信与加密样本对
勒索信（Readme.txt、HOW_TO_DECRYPT.html、!!!RESTORE!!!.txt 之类）里有家族标识、变种信息和受害者专属 ID，是判断这个版本有没有公开解密方案的前提。千万别因为"看着晦气"就删掉。
如果能找到同一个文件的加密前后两份（比如某个文档在个人电脑上还有干净副本，服务器上那份已被加密），把这一对样本留好，对判断加密方式和覆盖深度很有用。
另外留一两个小体积的被加密文件样本备查，但不要把数据库原件、客户资料、生产口令上传到任何公开检测站或贴到群里。
6. 系统与数据库日志
- Windows 事件日志（
.evtx，安全、系统、应用） - SQL Server 的
ERRORLOG系列 - 用友中间件 / Web 访问日志
这些日志有两个作用：一是确定加密发生的准确时间点，反推哪一次备份还是干净的；二是搞清楚入口到底是 SQL 弱口令被爆破、RDP 直接暴露在公网、用友相关漏洞，还是某台办公机先被远控木马拿下再横向进来的。入口不查清就恢复上线，二次加密的概率很高，而且第二次往往连刚恢复的数据一起带走。
正确的"保留"是什么样
保留不等于放着不管，有几个细节决定这些文件还能不能用：
- 副本至少两份，介质分开。一份扇区级镜像封存，一份工作副本用于后续尝试。镜像盘或拷贝目标盘最好是新的、空的、不接在被感染的网络里。
- 只读复制，不做任何"整理"。不要在原盘上删文件腾空间、不要杀毒软件对原盘执行"清除/隔离"（有些查杀会直接删掉被感染或被改写的文件）、不要重命名去掉后缀再试着附加。
- 记录原始路径和文件名。账套号、年度、原文件全路径、各文件大小，写下来。重组时这些信息能省不少事。
- 原盘断电封存。如果业务必须尽快恢复，用新盘重装系统上线，把原盘摘下来贴标签收好，而不是在原盘上重装。
几个会让数据彻底没救的动作
按造成不可逆后果的概率排：
- 在原盘上重装系统或重建分区。系统盘重装通常只覆盖系统分区，数据盘上的账套可能还在；但一旦格式化了数据盘或重建了分区表，原始数据被覆盖的程度就很难说了。相关的判断条件可以参考 重装系统之后还能不能恢复。
- 在唯一原件上反复运行来路不明的修复 / 解密工具。这类工具很多会原地写入，失败一次就改变一次文件内容，试几轮后连底层提取也做不了。工具提示不支持时更要停手，原因见 解密工具提示"不支持该文件"的几种情况。
- 反复强行附加损坏的数据库。SQL Server 在附加和修复过程中会尝试写日志、改文件头，让本来可提取的结构变得更乱。
- 删除"打不开的大文件"腾空间。这是最可惜的一种，损失通常是百分之百。
- 在未查清入口的情况下直接恢复上线，等于把干净备份送进同一个口子。
文件留住了，接下来怎么判断能恢复多少
保全完成后，判断顺序大致是：
- 先找干净备份。 有可用备份，优先走备份恢复 + 增量补录，这是最稳也最便宜的路径，不要先去折腾解密。
- 再看家族和加密方式。 根据勒索信和加密样本判断变种，确认是否存在公开可用的解密方案。多数流行家族目前没有免费解密器，但这一步仍要做，因为结论直接决定后面花多少钱、走哪条路。
- 最后评估碎片提取的可行性。 看加密到底覆盖了数据文件的多大比例、有没有完整的旧结构可做参照。这一步决定能捞回多少张表、断到哪个时间点。mdf 被加密后的可恢复性判断，可以先看 SQL Server 的 mdf 被加密还能恢复吗；账套层面的业务恢复顺序，和 金蝶账套的处置思路 基本一致。
这三条路是并列关系，不是递进关系，评估时可以同时推进，但破坏性的尝试必须放在副本上做。
什么时候该找人，什么时候自己就能办
如果备份完好、能直接还原到加密前的时间点，差额凭证手工补录即可，这种情况自己处理就行，重点反而是把入口堵住。
需要外部介入的通常是这几种：备份也被一起加密或早就失效；mdf 打不开且账套跨多年、数据体量大；加密还在继续或多台服务器、多个共享盘同时中招；查不出入口、担心恢复后再来一次。这时候的第一步也不是立刻解密，而是先做可恢复性评估——看现有文件还剩多少可用结构、走哪条路性价比最高，再谈方案。需要时可以通过 数据库与备份恢复评估 说明你手上现在还有哪些文件，或直接在 联系页面 描述情况。
还有一种容易被漏掉的情况：服务器被加密之前，财务或业务电脑先中了远控木马。这类事件除了数据，还牵涉账号会话和资金安全，主机清理和账号处置要分开做，处理思路见 银狐与远控木马相关说明。
最后回到一句话：现在的每一个删除动作，都在替未来的恢复做减法。 在没人评估过之前，让那块盘保持原样，是你现在能做的最有价值的事。
评论(0)