勒索病毒加密后mysqldump备份基本没用——若与数据库同挂载点、同权限且未启用不可变属性，备份文件大概率已被加密或删除；真正有效的离线备份需满足物理隔离、权限隔离和时间隔离。
勒索病毒加密后，mysqldump 备份还有用吗？
基本没用——如果备份文件和数据库在同一个挂载点、同一权限体系下，且未启用不可变属性，勒索病毒大概率已一并加密或删除。离线备份的关键不是“是否导出”，而是“是否脱离攻击面”。
-
mysqldump生成的是普通文件，无自动加密/隔离机制，放在 /backup/ 目录下和 /var/lib/mysql/ 同磁盘时，几乎等于没备份 - 真正有效的离线备份必须满足：物理隔离（不同主机/存储域）+ 权限隔离（非 MySQL 进程可写）+ 时间隔离（保留多版本，防覆盖）
- 常见误操作：定时任务用
root账户执行mysqldump并存到本地 NAS 共享目录——病毒拿到 root 权限后，NAS 挂载点同样沦陷
如何让备份文件“不可变”？Linux 下 chattr +i 真的可靠吗？
仅对单机有效，且需严格限制使用时机：chattr +i 只能防误删/覆盖，不能防提权后的 chattr -i。它不是安全边界，只是最后一道手动防护。
- 必须在备份写入完成、校验通过后，由独立账户（非
mysql、非root）执行chattr +i /backup/full_20240520.sql - 若备份目标是 NFS/CIFS 挂载点，
chattr无效——这些协议不透传 ext4/xfs 的 inode 属性 - 更稳妥的做法是配合对象存储的“对象锁定（Object Lock）”功能（如 AWS S3 Object Lock、MinIO Retention），服务端强制保留指定天数，连 root 都无法删除
MySQL 原生备份方案中，mysqlbackup 和 Percona XtraBackup 哪个更适合防勒索？
都不直接防勒索，但 Percona XtraBackup 因支持流式备份+加密传输+与对象存储直连，在落地不可变策略时更可控。
-
mysqlbackup（MySQL Enterprise Backup）依赖 Oracle 许可，且默认备份路径仍为本地目录，需额外脚本处理上传与锁定 -
xbstream流式输出可直接管道进openssl enc加密，再上传至 S3；整个过程不落盘明文备份文件 - 关键差异：XtraBackup 支持
--encrypt+--encrypt-key，而 mysqlbackup 的加密需靠外部工具或企业版密钥管理模块
备份恢复验证总失败，是不是备份本身就有问题？
90% 的情况是备份时没包含 mysql 系统库或忽略 GTID 一致性，导致恢复后权限丢失或主从断裂——这和勒索无关，但会让应急恢复雪上加霜。
- 务必在
mysqldump中显式加上--all-databases --routines --triggers --events，否则存储过程、事件调度器全丢 - 开启 GTID 的实例，备份命令必须带
--set-gtid-purged=ON，否则恢复后SHOW MASTER STATUS返回空，主从无法建立 - 验证不能只看
mysql -e "SELECT 1"，要实际执行一条跨库 JOIN 查询，并检查SELECT User,Host FROM mysql.user是否完整
