备份是复制MySQL数据与结构以备恢复，物理备份快但受限于系统与版本，逻辑备份通用但慢且资源消耗大；小库（50GB）优先选物理备份以缩短RTO。
备份就是把 MySQL 的数据和结构“抄一份”存起来；恢复就是在出事（比如误删、硬盘损坏、升级翻车）后，用这份“抄的”把数据库拉回某个时间点的状态。这不是可选项——生产环境没做备份，等于裸奔。
物理备份 vs 逻辑备份：选错类型，恢复时就卡死
物理备份是直接复制 ibd、frm、binlog 这类文件，速度快、恢复快，但有硬限制：innobackupex 或 xtrabackup 备份出来的文件只能恢复到同构系统（比如 Linux → Linux），不能跨平台（Linux → Windows）；也不能混版本（MySQL 8.0 备份不能直接恢复到 5.7）。逻辑备份是用 mysqldump 或 mysqlpump 导出 SQL 语句，文件可读、可编辑、可跨版本、可跨平台，但慢、占空间大、恢复时要重放 SQL，索引得重建，CPU 压力明显。小库（mysqldump；大库（>50 GB）、追求 RTO（恢复时间目标）xtrabackup。
全量、增量、差异：别只做一次全备就以为万事大吉
只做 mysqldump --all-databases 是最常见也最危险的习惯。全量备份（Full Backup）是基础，但每天全备 100 GB 数据，磁盘撑不住，网络也扛不住。真正可用的策略是“全量 + 增量”组合：xtrabackup 支持基于 binlog 位点或 LSN 做增量备份；mysqldump 本身不支持增量，得靠 binlog 解析来补。注意：增量备份依赖上一次全量或上一次增量的完整性，缺一个环节，整条链就断。差异备份（Differential）在 MySQL 生态中极少用——它虽比增量恢复快一步，但备份体积增长快，且主流工具（如 xtrabackup）默认不提供原生支持，容易自己造轮子翻车。
热备、冷备、温备：业务停不停，决定了你能不能按时发版
冷备 = systemctl stop mysqld && tar -czf backup.tar.gz /var/lib/mysql，简单粗暴，但业务中断；热备 = xtrabackup --backup --target-dir=/data/backup/full，数据库全程在线，但要求 innodb_file_per_table=ON、log_bin 开启，且必须在从库做（主库备份会加重 IO 和锁竞争）；温备本质是加全局读锁（FLUSH TABLES WITH READ LOCK），MyISAM 表常用，但 InnoDB 下等价于“半挂起”，写请求排队，高峰期慎用。真实线上，99% 的核心 MySQL 实例都走热备路径，且严格限定在从库执行——主库一抖，整个服务雪崩。
恢复不是“导入完就完事”：校验、权限、GTID 都可能让你白忙活两小时
用 mysql 导入 SQL 文件后，立刻查 SELECT COUNT(*) 不代表恢复成功——表存在，但数据可能被 SET SQL_LOG_BIN=0 绕过复制、或字符集不一致导致乱码；用 xtrabackup --copy-back 恢复后，忘了改 /var/lib/mysql 目录属主（chown -R mysql:mysql /var/lib/mysql），MySQL 启不起来；开启 gtid_mode=ON 的集群，恢复完没重置 gtid_purged，主从同步直接报错 ERROR 1236 (HY000)。最常被跳过的动作是：恢复后执行 mysqlcheck -u root -p --all-databases --check 校验表一致性，以及用 SHOW MASTER STATUS 确认 binlog 位点是否对齐。
