Navicat 不支持直接还原 .psc 文件，因其是 Percona XtraBackup 生成的物理备份格式，需先用 xtrabackup 命令行 prepare 和 copy-back 恢复实例，再通过 Navicat 连接验证。
Navicat 不支持直接还原 .
ps
c 备份文件
根本原因在于
是 percona server for mysql 的专有物理备份格式（基于 xtrabackup），
navicat
作为图形化客户端，只支持逻辑导入（如
）或部分厂商的云备份协议，不集成 xtrabackup 引擎。你双击或“还原”菜单里选
文件，大概率会报错
或直接无响应。
正确路径是：先用
命令行工具完成 prepare 和 copy-back，再让 Navicat 连接已恢复的实例查看数据。
还原 .psc 备份必须走命令行三步走
跳过这一步，Navicat 永远无法“看到”你的备份内容。整个过程不依赖 Navicat，它只是后续验证工具。
确保目标机器已安装匹配版本的
（MySQL 8.0）或
（MySQL 5.7）
解压
文件（它本质是 tar.gz 压缩包）：
执行 prepare（关键！否则数据文件不可用）：
停止 MySQL 服务，清空原数据目录（如
），再 copy-back：
改回数据目录权限：
Navicat 能做的只有验证和导出，不是还原主体
等 MySQL 实例成功启动后，Navicat 才派上用场：
PS CS6绿色精简版
最好用的图像处理软件
下载
新建连接指向该实例，确认库表存在、数据可查
若需导出某张表为
或
，可用 Navicat 的“数据传输”或“导出向导”
不要尝试在 Navicat 中“从备份恢复”，它没有调用
的能力，也读不懂
的物理页结构
注意：如果备份时启用了加密（
），prepare 阶段必须加
和
，否则 prepare 会卡住且无明确报错
容易被忽略的兼容性细节
看似流程固定，但几个点一错就全盘失败：
备份生成时的 MySQL 版本、Percona XtraBackup 版本，必须与 restore 环境严格一致，跨大版本（如 5.7 → 8.0）不支持
备份时若用了
且业务写入活跃，prepare 后可能遇到
，需检查
中的
是否连续
restore 目录磁盘空间要 ≥ 原数据目录的 1.5 倍（prepare 阶段会生成临时日志文件）
Navicat 连接后查不到新表？先确认 MySQL 的
配置是否真的指向你 copy-back 的目录，而不是默认路径
事情说清了就结束。真正耗时间的从来不是 Navicat 点几下，而是 prepare 是否成功、权限是否到位、版本是否咬合——这些地方没留神，重来一次就是小时级成本。
.psc.sql.pscunsupported file formatxtrabackuppercona-xtrabackup-80percona-xtrabackup-24.psctar -xzf backup.psc -C /path/to/restore/xtrabackup --prepare --target-dir=/path/to/restore//var/lib/mysqlxtrabackup --copy-back --target-dir=/path/to/restore/chown -R mysql:mysql /var/lib/mysql.sql.csvxtrabackup.psc--encrypt--decrypt--encrypt-key.psc--no-lockpage corruptionxtrabackup_checkpointsto_lsndatadir