Percona XtraBackup 备份不可直接挂载，需先解压（若启用--compress）再执行--prepare使数据一致，最后--copy-back恢复；其压缩文件为.qp格式，须用xtrabackup --decompress而非gunzip处理。
第三方工具本身不提供“挂载”功能，所谓“挂载压缩备份”是常见误解；真正可操作的是解压后恢复，或使用支持热备的工具（如 Percona XtraBackup）直接准备备份目录供恢复使用。
Percona XtraBackup 的备份文件不是普通压缩包，不能用 gunzip/bunzip2 解压
XtraBackup 生成的备份是原始数据文件（ibdata1、.ibd 等）+ 日志 + 元数据的集合，即使启用了 --compress 参数，它也只对单个文件做流式压缩（如 .qp 格式），并非标准 .tar.gz 或 .bz2。直接运行 gunzip backup/ 会报错：not in gzip format。
- 压缩备份需用
xtrabackup --decompress --target-dir=/path/to/backup解压（仅适用于--compress生成的.qp文件） - 解压后必须执行
xtrabackup --prepare --target-dir=/path/to/backup，否则数据不可用 - 跳过
--prepare直接拷贝到datadir启动 MySQL，大概率导致崩溃或无法启动
mydumper 的压缩备份可直接解压，但解压 ≠ 可用
mydumper 支持 --compress（默认用 zlib），生成的是 .sql.gz 文件，这类备份确实能用 gunzip 解压：
gunzip db1.table1.sql.gz
但要注意：
- 解压后得到的是 SQL 文本，不是数据库文件，不能“挂载”，只能用
mysql导入：mysql -u user -p db1 < db1.table1.sql - 若备份时用了
--trx-consistency-only或--no-schemas，解压后可能缺少建库/建表语句，导入会失败 -
myloader工具才是配套恢复程序，它能并行导入、自动建库建表，比手动mysql导入更可靠
别把 mysqldump 管道压缩当成“第三方工具备份”
像 mysqldump | gzip > backup.sql.gz 这类操作，本质仍是 mysqldump 的逻辑备份，gzip 只是外壳。它不属于第三方备份工具范畴，也不具备一致性快照、热备、增量等能力。
- 这种
.sql.gz文件可用gunzip或zcat解压，也可直接管道导入：zcat backup.sql.gz | mysql -u user -p db_name - 但它没有事务一致性保障（除非加
--single-transaction），大库备份期间写入可能导致数据不一致 - 无法“挂载”，也不能跳过导入直接让 MySQL 读取——SQL 文件不是数据文件
真正容易被忽略的点是：所有第三方工具的“压缩备份”都服务于后续恢复流程，而非提供类似磁盘镜像的挂载能力。是否需要解压、何时解压、解压后是否要 prepare，完全取决于工具类型和压缩方式——混用命令或跳过关键步骤，备份就等于白做。
