最关键判断点是确认是否存在未加密的离线备份；需验证其创建时间早于感染时刻，并检查文件是否被重命名或头部乱码，再通过mysqlcheck或测试环境还原验证可用性。
确认是否还有未加密的备份可用
这是整个恢复流程里最关键的判断点。勒索病毒（如 .malox、.sorry1、Loki）通常会主动扫描并加密网络共享、挂载卷、甚至删除系统卷影副本（VSS），但若你有物理隔离的离线备份（比如磁带、脱网NAS、或云上只读快照），且该备份创建时间早于感染发生时刻，那它大概率是干净的。
常见错误现象包括：误以为“本地备份目录没被删就是安全的”，结果发现备份文件本身已被追加了 .malox 后缀；或在感染后仍用自动脚本向同一存储写入新备份，导致全部污染。
- 立即检查备份路径下所有
.ibd、.frm、ibdata1文件是否被重命名或内容异常（例如开头 256KB 变成乱码 —— 这是Loki的典型行为） - 验证备份可还原性：不要只看文件存在，要用
mysqlcheck -c或尝试在测试环境执行mysqldump --no-data看能否读取表结构 - 若使用云厂商快照，确认其是否启用了“跨区域只读复制”或“不可变存储策略”，普通快照可能已被恶意进程覆盖
别在原服务器上直接解密或恢复
原环境大概率残留病毒进程、定时任务、恶意配置项（如 MySQL 的 plugin_dir 被篡改指向恶意 so 文件）。哪怕你杀掉了 mysqld，重启后仍可能被二次加密。
必须搭建全新环境，且满足以下条件：
- 操作系统重装，不复用旧系统盘镜像；数据库版本与原环境一致（例如原为
MySQL 8.0.33，避免用8.0.34直接还原ibd，因页面格式微调可能导致崩溃） - 禁用所有非必要网络接口，仅保留管理通道；关闭
skip-grant-tables、local_infile等高危选项 - 从备份恢复时，优先使用逻辑备份（
mysqldump输出的 SQL）而非物理文件（.ibd），前者更可控、可审计，也绕过 InnoDB 页面损坏风险
没有干净备份时，哪些文件还能抢救
当备份全毁，只能从加密残骸中捞数据时，重点盯住三类未被完全覆盖的区域：
-
FRM文件：多数勒索病毒（如Loki）只加密前 256KB，而小表的FRM往往不足此大小 → 全文件被毁，但大表的FRM可能残留字段定义，可用strings命令提取 -
IBD文件：大于 512KB 的文件通常只加密头尾各 256KB，中间数据页（page）仍完好 → 用mysql_innodb_page_stream扫描有效 page，再用mysql_innodb_salvage_dul-V2.8.exe提取行记录 - 二进制日志（
binlog）：若未被删除且格式未损坏，可通过mysqlbinlog解析出感染前的INSERT/UPDATE语句，人工拼凑关键业务数据
注意：.sorry1 类病毒会强制删除 VSS，Windows 平台下别浪费时间找卷影副本；.devos 病毒加密强度高，目前无公开解密工具，强行用非官方“解密器”大概率损坏文件结构。
加固不是加个密码就完事
勒索病毒入侵 MySQL，90% 源于外围暴露面：弱口令、公网开放 3306 端口、未更新的漏洞（如 CVE-2021-42574）、或通过 Web 应用漏洞反向连接数据库。单纯给 root 改强密码，挡不住已植入的持久化后门。
- 检查 MySQL 用户列表：运行
SELECT user,host FROM mysql.user;，删掉所有'%'@'%'或陌生 host 的账号 - 审计插件与 UDF：执行
SELECT * FROM mysql.plugin;和SELECT * FROM mysql.func;，移除非官方来源的动态库 - 限制网络暴露：用防火墙（如
iptables或云安全组）仅放行应用服务器 IP 访问 3306，禁用bind-address = 0.0.0.0 - 启用审计日志：配置
plugin_load_add = audit_log，记录所有连接与查询，便于事后追溯攻击链路
最易被忽略的一点：备份本身也要加固。把备份脚本的密码硬编码在 crontab 里，等于给攻击者递钥匙；应改用 MySQL 的 mysql_config_editor 存储加密登录信息，或用 Vault 类工具动态注入凭证。
