物理备份恢复失败主因是目录结构不匹配，要求数据目录层级、命名、权限、空目录等与原实例完全一致，否则innodb启动时报错找不到文件；innodb_file_per_table必须源目标一致并重启生效；.cfg、.isl、undo文件等隐形依赖不可遗漏；os路径、权限、符号链接须严格对应。
物理备份恢复失败常因目录结构不匹配
MySQL物理备份不是“拷几个文件就行”，而是要求整个数据目录的层级、命名、权限、甚至空目录都必须和原实例一致。否则启动时直接报错，比如InnoDB: Operating system error number 2或Tablespace is missing for table 'db.t1'——这不是配置没改对，是InnoDB在找文件时根本找不到路径。
innodb_file_per_table决定.ibd是否独立存在
这个参数控制表空间是写进共享表空间（ibdata1）还是每个表单独一个.ibd文件。如果备份里有db/t1.ibd，但目标实例innodb_file_per_table=OFF，mysqld启动时会忽略它；反过来，若源库是ON、备份含.ibd，而目标库OFF且没重启生效，ALTER TABLE ... IMPORT TABLESPACE会失败。
- 恢复前务必查源库：
SELECT @@innodb_file_per_table; - 检查备份目录中是否存在对应
.ibd文件：有则说明依赖独立表空间 - 目标实例必须提前设好同值并重启，不能仅靠
SET GLOBAL
cfg、.isl、undo文件这些“隐形依赖”容易被忽略
物理备份不只是.ibd和ibdata1。XtraBackup或MEB会自动包含.cfg（表结构元数据）、.isl（表空间路径映射）、undo_001等文件。手动用rsync或cp复制时，若漏掉.cfg，IMPORT TABLESPACE会报Invalid or missing tablespace file；若undo文件版本不匹配，--prepare阶段就中断。
-
.cfg文件必须和.ibd同名同目录，且内容中的root_path字段需与目标实例实际路径一致 -
undo_*文件数量、大小、LSN范围必须与ibdata1和redo log对齐，否则xtrabackup --prepare失败 - 加密表空间还额外依赖
keyring/子目录及其权限（MySQL进程需可读写）
OS路径差异会导致文件“存在却不可见”
Linux下/var/lib/mysql/db/t1.ibd和/data/mysql/db/t1.ibd是两个完全不同的路径。即使你把文件全拷过去了，如果my.cnf里datadir指向错误路径，或者mysql用户对目标目录无执行权限（chmod 750不够，得755才能进入子目录），InnoDB初始化时就会跳过整个目录树。
- 确认
datadir值：SELECT @@datadir;，再核对备份中文件实际存放位置 - 检查权限链：
ls -ld /var/lib/mysql /var/lib/mysql/db，确保每级目录对mysql用户有x权限 - 符号链接（symlink）必须真实存在且指向有效路径，InnoDB不跟随
../跳转
.isl、或者datadir末尾多了个/，都可能让整个实例卡在初始化阶段。
