数据库附加成功、服务能启动、SSMS 里能看到表，这三件事只说明文件结构能被引擎读进去，不说明里面的业务数据是完整的。尤其是走过碎片提取、或者用过 REPAIR_ALLOW_DATA_LOSS 的库，页损坏会被直接丢弃，界面上不会报错，丢的记录要等财务月底对不上账才被发现。
核对要按层来，顺序不能倒：先保住副本 → 引擎级一致性 → 约束与关系 → 账号权限 → 恢复时间点 → 业务与财务对账 → 隔离环境联调。上一层没过就往下走，后面查出来的问题全是误判。
动手前必须先做的三件事
1. 把恢复出来的这份库复制一份，之后所有检查都在副本上做。
如果这是碎片提取或专用工具修复出来的唯一结果，它就是原件。一旦你在它上面跑修复命令、重建索引、删重复数据，出错就没有第二次机会。正确做法是先对它做一次完整备份（BACKUP DATABASE ... TO DISK），把 bak 文件和原始的 mdf/ldf 另存一份到离线盘，再把副本还原成一个新库名用于验证。原始被加密的文件、服务器镜像同样不要删——后面如果需要换恢复路径，还得回到它们。
2. 别接进生产网，也别让用户开始录数据。
很多单位急着复工，库一还原就让业务上线，结果核对时发现缺三天数据，这时新旧数据已经混在一起，想重新还原就得把新录的再导一遍。核对期间保持隔离，一方面避免边用边查，另一方面也防止恢复环境和还没清干净的内网再次接触。如果攻击过程中出现过断网后文件仍在被加密的情况，先确认加密确实已经停止再谈恢复验证。
3. 把“这份数据是怎么来的”写清楚。
不同恢复路径，排查重点完全不同：
- 完整备份 + 日志还原到时间点：结构一般完好，重点查时间点和差额区间；
- 只有较旧的完整备份：结构完好，重点查缺了多少天，谁来补录；
- 数据库文件被部分加密后做碎片提取／工具修复：重点查页级损坏和表内数据错位；
- 执行过
DBCC CHECKDB ... REPAIR_ALLOW_DATA_LOSS：重点查被丢弃的页对应哪些表、哪些记录。
第一层：引擎级一致性检查
在副本上执行：
DBCC CHECKDB ('你的库名') WITH NO_INFOMSGS, ALL_ERRORMSGS;它会检查分配结构、系统目录、索引和每张表的物理与逻辑一致性。返回结果里没有任何错误信息，才算这一层通过；库大的话这条命令可能跑很久，让它跑完，不要中途取消。
如果报出了一致性错误，先别急着按提示跑修复。微软给出的修复建议是最低可用级别，REPAIR_ALLOW_DATA_LOSS 的字面含义就是“允许丢数据”——它靠丢弃损坏页让库上线，丢掉的是整页记录。正确顺序是：记下错误涉及的对象 ID 和页号，先确认还有没有更干净的备份或副本可用；只有在确认没有其他路径、且已经做好当前状态的完整备份之后，才考虑修复。
已经跑过强制修复的情况，这一层要反向做一次功课：翻出当时的执行输出和 SQL Server 错误日志，把提示被删除／被修正的页记录下来，通过页号定位到具体表（DBCC PAGE 或对象 ID 反查），列出“这几张表可能缺记录”的清单，交给业务侧在后面的对账里重点看。这一步省掉，后面丢的数据基本查不出来。
第二层：约束与表间关系
结构能读不代表关系是对的。日志回滚不完整、碎片拼接错位，都会留下“有明细没主单”“有出库单没有对应商品”的孤儿记录，应用层打开这张单据就会报错或显示金额为零。
DBCC CHECKCONSTRAINTS WITH ALL_CONSTRAINTS;整库跑代价较高，时间紧就对核心表单独跑（DBCC CHECKCONSTRAINTS ('表名')）。返回结果里列出的每一条违反记录，都要人工看一眼是业务本来就允许，还是这次恢复造成的断裂。
另外两件容易漏的事：
- 自增列的种子值。用
DBCC CHECKIDENT ('表名', NORESEED)比对当前标识值和表内最大值，不一致会导致新单据插入时主键冲突。 - 不靠外键维护的关联。很多国产业务系统和老账套根本没建外键，靠程序保证关系，这时 CHECKCONSTRAINTS 查不出问题，只能写 SQL 手工比对主从表：按单据号
LEFT JOIN找出明细表里主表不存在的单号。
第三层：登录名、数据库用户和权限
换了实例或重装过 SQL Server 之后，实例级登录名（Login）和库内用户（User）的 SID 会对不上，形成孤立用户，表现就是应用连不上，或者连上了但存储过程执行报权限错误。查一下：
SELECT dp.name, dp.type_desc, dp.sid
FROM sys.database_principals dp
LEFT JOIN sys.server_principals sp ON dp.sid = sp.sid
WHERE dp.type IN ('S','U','G') AND sp.sid IS NULL
AND dp.name NOT IN ('guest','INFORMATION_SCHEMA','sys');对查出来的用户用 ALTER USER [用户名] WITH LOGIN = [登录名] 重新映射。顺带确认 SQL Server 代理里的作业、维护计划、链接服务器和数据库邮件是不是也一并恢复了——这些在只还原用户库时不会带过来，备份作业没了会导致“恢复完又裸奔”。
重设的账号密码不要沿用旧的。 如果这次是勒索事件，sa 和业务账号的口令大概率已经泄露，改密码要在确认干净的设备上做。
第四层：确定恢复到了哪一刻，缺口有多大
这一层决定补录工作量，必须给业务一个明确的时间边界。
对订单表、流水表、凭证表、出入库单、操作日志表这些核心流水表，查最后一条记录：
SELECT MAX(单据日期), MAX(创建时间), COUNT(*) FROM 订单表;
SELECT CAST(创建时间 AS DATE) d, COUNT(*) FROM 订单表
WHERE 创建时间 > '2024-01-01' GROUP BY CAST(创建时间 AS DATE) ORDER BY d DESC;按天统计的条数曲线比一个 MAX 值更有用：如果最后几天的单量突然只剩平时的几分之一，说明丢的不只是尾部时间段，而是数据本身有缺口，要回到第一层去找原因。
还要注意三点：
- 攻击往往比发现早。加密发作前攻击者可能已经在里面待了几天，期间的数据未必可信，时间窗口要往前多看一段。
- 多个库的时间点未必一致。主业务库、附件库、中间库如果来自不同备份，彼此之间会错位，跨库单据会对不上。
- 数据库之外的文件。ERP 的附件、扫描件、影像资料、导出报表通常存在文件系统里，数据库恢复了不代表这些文件没被加密，路径能查到但文件打不开的情况很常见，要单独清点。
第五层：业务和财务自己对账
前四层是 IT 的活，这一层必须让用账的人来做，IT 看不出金额是否合理。重点比对：
- 财务：科目借贷是否平衡、总账与明细账是否相符、期初余额与上期结账数是否一致；
- 进销存：期初期末的数量与金额结存、库存台账与实物抽盘；
- 未完结单据：待审核、待出库、挂起结算的单据状态有没有异常卡死或状态回退；
- 关键主数据：客户、供应商、物料、价格表的条数与最近修改记录。
金蝶、用友这类标准账套自带账套检测、结账检查或对账工具，直接跑一遍，比手工抽查覆盖得全。不同版本的检测项和修复能力差别较大，检测报告里提示的“可自动修复”项，在没有确认备份之前也不要随手点修复。
第六层：隔离环境里走一遍完整业务
把业务系统挂到这个副本库上，在内网隔离环境中做端到端验证：各模块能正常登录、报表能出数、历史单据能调阅打印，然后实际新建一笔单据并完成审核、修改、反审核、删除的全流程。这一步查的是只读检查发现不了的问题：标识列冲突、触发器缺失、存储过程被丢页破坏、索引损坏导致的查询超时。做完把测试单据删掉。
验证通过后，立刻对这个库做一次全新的完整备份，再切到生产，然后按“先停写入、再导入补录数据、最后开放全员使用”的顺序上线，并安排一段观察期，让业务在使用中继续发现零散问题。
如果对不上，先分清是哪一类问题
- 整段时间缺失：属于备份覆盖范围问题，往影子副本、日志备份、异机同步、第三方备份一体机、业务系统的中间表或前置机里继续找可用副本，还能往回捞一点是一点；
- 结构损坏、页丢失：说明当前这条恢复路径已经损失了数据，要评估是否换用另一份原始文件重新提取，而不是在已经修复过的库上继续修补；
- 数据错位、乱码、金额明显离谱：多见于碎片提取拼接，需要回到原始文件层面重做，在业务库上用 SQL 改数据只会掩盖问题。
判断到底还能不能捞回更多，取决于原始文件被加密的程度、还剩哪些副本、以及之前做过哪些操作，这部分需要看实际文件才能评估，光凭现象说不准。如果你手里只剩下一份被加密的 mdf、或者强制修复后发现缺了关键几个月的数据，可以先停止一切写入和修复动作，保留现状，再做备份与数据库恢复路径的评估；不确定当前数据库文件是被哪类加密影响、还有没有解密可能的，也可以先做家族识别与可恢复性判断。
最后提醒一句：核对通过只说明数据可用，不说明系统安全。入侵路径没查清、口令没换、备份没重建之前上线，很容易几周后再来一次。恢复验收和安全加固是两件事，都要做完才算收尾。
评论(0)