物理备份常跳过ibtmp1、#sql-.ibd、#sql-.frm、错误日志、慢查询日志、通用日志及二进制日志等非关键文件，因其可重启重建且不参与一致性恢复。
物理备份体积比数据目录小，大概率是备份工具跳过了临时文件和日志
物理备份（比如用 rsync、tar 或 mysqlbackup）默认不会无差别复制整个 /var/lib/mysql 目录下所有文件。很多工具会主动忽略运行时生成的临时或可重建文件，导致备份体积明显小于 du -sh /var/lib/mysql 的结果。
哪些文件常被物理备份跳过？
这些文件不参与一致性恢复，且重启服务后能自动重建，所以多数备份策略会排除它们：
-
ibtmp1：InnoDB 临时表空间，默认随 mysqld 启动创建，关机即删；若innodb_temp_data_file_path未设为固定大小，它会被跳过 -
#sql-*.ibd和#sql-*.frm：ALTER 过程中残留的临时表文件，属“幽灵文件”，备份工具通常不认 - 错误日志（
mysqld.err）、慢查询日志（slow.log）、通用日志（general.log）：纯文本日志，非数据文件，mysqldump和mysqlbackup默认不包含 - 二进制日志（
binlog.000001等）：除非显式启用--include-binlogs（如mysqlbackup），否则不进备份包
如何验证备份是否漏了关键数据文件？
别只比总大小，要逐项核对备份内容与实际数据目录结构：
- 用
tar -tzf backup.tar.gz | grep '\.ibd$'查看备份里有哪些.ibd文件，再对比ls /var/lib/mysql/*/ | grep '\.ibd$' - 检查备份是否含
ibdata1（共享表空间）或每个库下的db.opt—— 缺失说明可能用了不完整路径备份 - 运行
mysqlbackup --backup-dir=/path/to/backup list-backup（如果是 MySQL Enterprise Backup），它会明确列出“Excluded files” - 如果用
rsync自建脚本，确认没加--exclude='*.err' --exclude='ibtmp1'类参数——有时候排除逻辑写死了但忘了同步更新
真正危险的是“看起来一致，其实漏了系统表空间”
最容易被忽略的是 ibdata1 和 mysql.ibd 的状态。如果 innodb_file_per_table=OFF（虽已不推荐，但老实例仍存在），所有表数据都挤在 ibdata1 里；此时若备份只拷了各库子目录而漏掉 ibdata1，恢复后所有表都会变成空壳。务必先查 SHOW VARIABLES LIKE 'innodb_file_per_table';，再决定备份范围是否覆盖根目录级文件。
