在某些情况下，非事务性表（例如 MyISAM表）的备份可能包含其他未提交的数据。如果 关闭自动提交InnoDB，并且在同一个事务中同时修改了表和非事务表，则可以在更新二进制日志位置之前将数据写入非事务表。提交事务时更新二进制日志位置，但立即写入非事务数据。如果在此类事务打开时进行备份，则备份数据包含对非事务表所做的更新。

如果mysqlbackupkill -9进程被 Unix命令等 中断，FLUSH TABLES WITH READ LOCK操作可能会继续运行。在这种情况下，使用KILL QUERY来自mysql 命令行的语句来终止该FLUSH TABLES WITH READ LOCK语句。FLUSH TABLES如果操作因长时间运行的查询或事务而停止，则更有可能发生此问题。有关备份时间和性能的指南，请参阅 第 11.1 节“优化备份性能”。

不要在备份操作进行时运行DDL 操作（例如， ALTER TABLE、TRUNCATE TABLE、 OPTIMIZE TABLE、或 ）。生成的备份可能会损坏。 REPAIR TABLERESTORE TABLECREATE INDEX

表中的engines列 mysql.backup_history未正确反映备份数据库的存储引擎。

由于在备份运行时在服务器上生成巨大的重做日志文件，具有大量写入工作负载（例如，每分钟千兆字节的数量级）的大型数据库的热备份可能需要很长时间才能完成。但是，当频繁修改的是数据库中相对较小的表子集时，可以使用乐观备份功能来提高性能并减少备份大小以及备份和恢复时间。有关详细信息，请参阅 第 4.3.6 节，“进行乐观备份”。

虽然可以使用 MySQL Enterprise Backup 备份到网络附加存储 (NAS) 设备或从中恢复，但由于可能出现的网络问题，备份的一致性以及备份或恢复操作的性能可能会受到影响。

当使用可传输表空间 (TTS)为包含 Antelope 和 Barracuda 文件格式混合的表的服务器 创建备份时 ，不要对表应用完全锁定（即，不要指定 --use-tts=with-full-locking）。相反，只需指定--use-tts或 --use-tts=with-minimum-locking，这两者都会对表应用最小锁定。

当在共享表空间中创建任何（或所有）分区时， 使用可传输表空间 (TTS) 备份分区表 将失败。

如果任何分区是在备份服务器的数据目录之外创建的 ，即使使用该 选项，恢复使用可传输表空间 (TTS) 备份的分区表 也会失败。--force

如果在使用可传输表空间 (TTS) 创建备份时在服务器上执行数据定义语言 (DDL) 语句 ，备份可能会失败。这是因为没有被备份的表在备份过程中没有被锁定，但是mysqlbackup在过程结束时仍然检查那些表的状态，如果那些表的定义被改变了可能会出错。为避免此问题，请勿执行任何 DDL 操作，尤其是 DROP TABLE在进行 TTS 备份时。

如果使用可传输表空间 (TTS) 备份包含全文搜索 (FTS) 索引的 表，则在恢复后，FTS 索引将损坏。用户将需要使用以下命令重新创建索引：

mysql> ALTER TABLE mytable ENGINE = INNODB;

然后，检查表是否不再有错误：

mysql> CHECK TABLE mytable;

在 MySQL 服务器上以 SQL 方式创建的表 不能使用可传输表空间 (TTS)ANSI_QUOTES进行备份 。

MySQL Enterprise Backup 不.pem将服务器中的文件包括到备份中。当启用 SSL 连接时，这些文件是服务器实例的一部分。

备份 MySQL 5.7 实例时，如果在备份过程中发出CREATE INDEXwith 语句ALGORITHM = INPLACE，因为该语句不会进入 MySQL 5.7 服务器的 redo log（详见Sorted Index Builds），所以不能记录在备份中，恢复备份时mysqlbackup不会重新创建索引。

当服务器数据目录的子目录下存在无法识别的文件类型的文件时，除非 使用该选项，否则将由mysqlbackup备份。--only-known-file-types但是，如果文件名没有扩展名，则会导致mysqlbackup在尝试将备份恢复到服务器时抛出错误。

macOS 和 Windows 平台以及 Linux 平台上不支持 MySQL Enterprise Backup 的云操作，当通用 Linux 构建用于服务器和 MySQL Enterprise Backup 时（即，当服务器和 MySQL Enterprise Backup 都使用通用安装时） Linux 压缩包）。

将--src-entry选项与extract云备份命令一起使用将导致命令失败。云备份只能完整提取。

当mysqlbackup使用加密的 InnoDB 表 时，一些限制适用。有关详细信息，请参阅 此处的讨论。

如果重做日志页的校验和 在服务器上 被禁用（即，如果 --innodb_log_checksums是 OFF或），备份操作可能会失败。 FALSE0

当通用表空间与数据库的系统表空间具有相同的基本名称（通常是ibdata1）并且存在于与其相同的目录（通常是服务器的数据目录）中时，压缩目录备份将失败。在相同情况下创建的压缩单文件备份将损坏，并且无法恢复。为避免此问题，服务器管理员不应将系统表空间和具有相同基本名称的通用表空间放在同一目录中；如果这是不可避免的，请不要对数据库执行压缩备份。

当使用其源服务器也属于单独的组复制设置的复制设置时，随着时间的推移，从源服务器或副本创建一致的备份，但不是同时从两者创建备份。否则，源和副本生成的值会发生冲突 id，导致备份失败。

如果任何数据库的名称与任何撤消表空间的名称相同，则备份将失败。为使备份成功，数据库管理员应避免为任何数据库和撤消表空间赋予相同的名称（例如，使用默认的撤消表空间名称undo_001来命名数据库），或者应在备份前重命名数据库。

包含任何表并在备份开始前被删除的数据库在恢复备份时显示为空数据库。必须从恢复的服务器中再次手动删除删除的数据库。