业内新闻

数据库恢复删除的数据：一个工程师的“战场”手记

开头——先问个问题：你有没有在凌晨三点，盯着屏幕上的“DELETE FROM table_name WHERE 1=1”发呆？我知道那种感觉。干这行十几年，处理过的“数据库恢复删除的数据”案例少说也有几百次。每次接到电话，对方第一句话往往是“完了，全没了”。但别急，数据往往没真的“消失”，只是藏得深了点。 www.fixhdd.cn

今天这篇东西，我不打算写得像教科书。我会一边回忆真实案例，一边把判断逻辑、操作节点、坑和技巧都抖出来。中间可能跳跃，也可能突然纠正自己——毕竟现场恢复从来不是线性的。

www.fixhdd.cn

故障判断：先别碰数据库，问三个问题

很多朋友一发现数据丢了，立刻启动数据库、运行各种修复工具——这是最致命的。你越着急，覆盖的可能性越大。记住第一守则：写保护。

www.fixhdd.cn

问题一：删除操作是什么时候发生的？ 如果刚刚发生，事务日志可能还在，回滚是最佳路径。如果过了几天，日志被截断或归档，就得换思路。
问题二：用的是哪种数据库？ MySQL 的 InnoDB 和 MyISAM 恢复逻辑完全不同；SQL Server 的完整恢复模式与简单模式差异极大；Oracle 的 UNDO 表空间深度决定恢复上限。
问题三：有没有其他进程写入？ 哪怕一个简单的 checkpoint 都可能把旧数据页覆盖。我会先让客户关掉所有应用服务，甚至拔网线——听起来夸张，但很重要。

顺便说一句，有次帮一家电商公司恢复数据，他们的 DBA 在误删后 40 分钟里尝试了 3 次重启和 2 次备份恢复，结果把仅存的日志文件也搞坏了。后来我们通过技王数据恢复的底层扫描工具，硬是从磁盘碎片里拼出了 80% 的订单记录。那次之后，他们再也不敢乱操作了。 www.fixhdd.cn

常见场景：事务日志与回滚

如果删除操作还在未提交事务内，恭喜，直接 ROLLBACK 就行。但更多情况是提交了，甚至执行了 TRUNCATE。这时就要看日志：MySQL 的 binlog 如果开启且格式为 ROW，可以解析出旧数据；SQL Server 的 事务日志 LSN 链没断的话，用 fn_dblog 函数能提取。这些操作需要非常谨慎，一个错误的 CHECKPOINT 可能永久丢失剩余数据。技王数据恢复

小案例：差点被“备份”坑了

一个朋友的公司用的是 PostgreSQL，某天误删了一个核心表。他们立刻恢复了一个 24 小时前的全量备份，结果发现备份文件本身就有坏块，而且最近 48 小时的 WAL 日志被自动清理了。我们只能通过文件系统级别的工具去扫描数据目录里未被覆盖的旧文件——从 8TB 硬盘里找到了 3GB 的残留数据页，再结合索引重建，总算没让业务断档。这个案例说明：备份不等于保险，日常要检查备份完整性。

www.fixhdd.cn

核心操作步骤：当数据“表面”已消失

下面列的操作顺序不是死板的，要根据实际情况调整。比如，如果判断日志还在，直接走步骤 2；如果日志早没了，跳步骤 3。技王数据恢复

立即冻结环境：停止数据库服务（小心，不能粗暴 kill，最好 service stop 或 shutdown immediate），然后对整个数据卷做 dd 镜像或快照。镜像要保存到独立硬盘，避免二次写。
尝试逻辑恢复：
- MySQL: 查看 binlog 文件，用 mysqlbinlog 工具解析出被删除的 INSERT 语句，反向生成 INSERT 脚本。注意 binlog 位置。
- SQL Server: 用 DBCC LOG 或第三方工具分析事务日志，提取 LOP_DELETE_ROWS 记录之前的行数据。
- Oracle: 如果 UNDO 表空间足够大，可以用 Flashback Query 或 Flashback Table 直接找回。
底层扫描（物理恢复）：当逻辑层不可用，就得深入到页级别。InnoDB 每个表空间文件（.ibd）里数据页有固定大小（默认 16KB），页头有校验和、事务 ID 等。我们可以通过页分析工具（如 Undelete for InnoDB 或自己写的解析脚本）找出被标记删除但尚未被覆盖的记录。注意：innodb_file_per_table 模式下恢复难度较低，共享表空间则复杂得多。
应用日志与数据重组：将找回的原始行按主键或唯一键去重，结合系统表 information_schema 或 sys.objects 恢复表结构。然后分批 INSERT 回新库。
验证完整性：使用业务逻辑交叉检验，比如订单表恢复后要跟支付记录对应。如果发现外键冲突，可能要人工干预修正。

注意事项：绕开那些“看上去正确”的陷阱

别信“快速修复”工具：很多数据库管理工具自带的“恢复删除数据”功能只针对表级回收站，对于底层页释放没用。
存储引擎差异很大：MyISAM 没有事务日志，一旦删除很难通过日志恢复，只能靠文件系统还原。而 InnoDB 有 doublewrite buffer 和 undo log，更有可能。
版本兼容性：某些旧版 MySQL 的 binlog 格式默认 STATEMENT，无法直接恢复具体行。建议升级到 ROW 格式，并定期刷新。
小心“回滚段”被覆盖：Oracle 的 UNDO 表空间如果设置了自动扩展且自动删除，恢复机会窗口极短。我见过一个案例，错误地在 UNDO 表空间上执行了 ALTER TABLESPACE UNDO ADD DATAFILE，直接把旧数据覆盖了。

经验案例：凌晨三点的抢救

“技王数据恢复”的同事曾经接手过一个财务系统：SQL Server 2016，完整恢复模式，DBA 不小心运行了一个本应带 WHERE 条件的 UPDATE 语句变成全表更新，而且十分钟后才发现。没有 HA 环境，只有一个三天前的完整备份。他们当时没有慌，先获取了日志备份链（所有未截断的 .trn 文件），然后用 ROLLBACK 信息结合 fn_dblog，逐个事务提取出误更新前的前镜像。但问题来了：日志里只保留了最近几小时的操作，更早的被维护作业截断了。还好误更新前两小时有一个差异备份，他们先还原到差异备份时间点，然后在这个基础上应用截断后的日志（跳过误操作那条 LSN），最终成功恢复了 90% 的数据。关键点：他们知道如何利用 STOPAT 参数配合 MARK 事务。

技王数据恢复

这个案例告诉我们：差分备份和日志备份不能断，而且一定要做恢复演练。很多公司只备份不测试，到真正需要时才发现日志文件损坏或备份集不完整。