mysqldump备份在勒索攻击后基本失效，除非满足物理隔离、权限隔离和时间隔离；chattr +i不可靠，真正不可变需依赖对象存储锁定或只读快照；恢复应优先使用含--all-databases等参数的逻辑备份，docker中须避免bind mount裸露数据目录。
mysqldump 备份在勒索攻击后基本失效——除非它物理隔离、权限隔离、时间隔离，否则大概率已被加密或覆盖。
确认备份是否真“离线”而非“假离线”
很多人以为把 mysqldump 输出文件 cp 到 /backup/ 就算备份了，但若该目录和 /var/lib/mysql 在同一挂载点、同一用户可写，病毒拿到 MySQL 进程权限后就能顺手加密所有文件。
必须检查三点：
• 备份路径是否跨物理设备（如独立 NAS、磁带、云对象存储）
• 写入备份的账户是否与 MySQL 进程分离（禁用 root 或 mysql 用户执行备份脚本）
• 是否保留多版本（如按日期命名 full_20260628.sql），避免被覆盖
别信 chattr +i 能防勒索
chattr +i 只对本地 ext4/xfs 文件系统有效，且一旦攻击者提权，立刻能 chattr -i 解除锁定。更糟的是：
• NFS/CIFS 挂载点不支持 inode 属性透传，chattr 完全无效
• 容器内 /backup 目录若映射到宿主机，chattr 作用域仅限容器层，宿主机仍可删改
真正可靠的不可变性得靠服务端能力：AWS S3 Object Lock、MinIO Retention Policy、或云厂商提供的“只读快照+跨区域复制”
恢复时优先用逻辑备份，别直接搬 .ibd 文件
物理文件恢复风险极高：
• MySQL 版本微调（如 8.0.33 → 8.0.34）可能导致 ibd 页面格式不兼容，启动即崩溃
• Loki 类病毒常只加密 .ibd 前 256KB，中间数据页虽完好，但需工具（如 mysql_innodb_page_stream）提取，非标准流程
• mysqldump 输出的 SQL 是文本，可人工审计、跳过损坏表、重跑建库语句，可控性强
务必在备份命令中显式加参数：--all-databases --routines --triggers --events --set-gtid-purged=OFF，否则恢复后权限、存储过程、GTID 全丢
Docker 环境里，bind mount 是最大隐患
很多 Docker MySQL 镜像用 -v /host/mysql:/var/lib/mysql 挂载，等于把数据库裸盘暴露给宿主机——病毒一旦攻陷容器，就能通过挂载点直接加密宿主机上所有 .ibd 和 .frm 文件。
正确做法：
• 改用 named volume（docker volume create mysql-data），Docker 自动管理底层存储，宿主机不可见原始文件
• 若必须 bind mount，确保宿主机目录有严格 ACL（setfacl -m u:mysql:r-x /host/backup），且备份脚本不运行在容器内
• 禁用 docker exec -it mysql bash 后手动操作，所有运维走 API 或专用管理容器
/var/log/mysql/、篡改定时任务，所以验证必须脱离原环境，在干净机器上用 mysqlcheck -c 或 mysqldump --no-data 实测能否读出表结构，而不是只看文件存在。
