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

如果mysqlbackup进程被中断，例如Unixkill - 9命令,用读锁刷新表操作可能仍在运行。在本例中，使用杀死查询来自mysql命令行杀死用读锁刷新表声明。此问题更有可能发生，如果刷新表操作因长时间运行的查询或事务而暂停。指第11.1节“优化备份性能”有关备份时间和性能的指导方针。

不要运行DDL操作(例如，ALTER TABLE，截断表，优化表，修理表，恢复表或创建索引)，而备份操作正在进行。生成的备份可能会损坏。

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

对于具有大量写入工作负载的大型数据库(例如，每分钟千兆字节)，热备份可能需要很长时间才能完成，因为备份运行时在服务器上生成了巨大的重做日志文件。但是，如果频繁修改的是数据库中相对较小的表子集，则可以使用Optimistic Backup特性来提高性能、减少备份大小以及备份和恢复时间。看到第4.3.6节“乐观备份”获取详细信息。

虽然可以使用MySQL Enterprise backup从网络连接存储(NAS)设备进行备份或恢复，但由于可能出现的网络问题，备份的一致性和备份或恢复操作的性能可能会受到影响。

创建备份时使用可迁移表空间对于包含混合了Antelope和Barracuda文件格式的表的服务器，不要对表应用完全锁定(也就是说，不要指定——use-tts = with-full-locking)。相反，只要指定——use-tts或——use-tts = with-minimum-locking，两者都将对表应用最小的锁。

分区表的备份可迁移表空间当它的任何(或所有)分区在共享表空间中创建时将失败。

恢复使用备份的分区表可迁移表空间，即使当——力选项，如果任何分区是在备份服务器的数据目录之外创建的，则会失败。

在使用创建备份时，如果在服务器上执行了DDL语句可迁移表空间，备份可能会失败。这是因为没有备份的表在备份过程中没有被锁定，但是mysqlbackup仍然在流程结束时检查这些表的状态，如果更改了这些表的定义，则可能发生错误。为了避免这个问题，不要执行任何DDL操作，特别是删除表，当TTS备份正在进行时。

如果包含全文检索(FTS)索引的表使用可迁移表空间，恢复后，FTS索引将被破坏。用户需要使用以下命令重新创建索引:

ALTER TABLE mytable ENGINE = INNODB;

然后，检查表是否有更多错误:

mysql> CHECK TABLE mytable;

在MySQL服务器上创建的表ANSI_QUOTESSQL模式不能使用可迁移表空间．

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

在备份MySQL 5.7实例时，如果a创建索引声明与算法= inplace是在备份过程中发出的，因为该语句不会进入MySQL 5.7服务器的重做日志(参见排序索引构建，则备份中无法记录该索引mysqlbackup恢复备份时。

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

MySQL企业备份的云操作在macOS和Windows平台上不受支持，当服务器和MySQL企业备份都使用通用Linux构建时(即，当服务器和MySQL企业备份都使用通用Linux tarball安装时)，在Linux平台上也不受支持。

使用——src-entry选项中的提取云备份上的命令将导致该命令失败。只能完全提取云备份。

以下情况适用一些限制mysqlbackup适用于加密的InnoDB表．看到这里的讨论获取详细信息。

如果重做日志页的校验和被禁用，备份操作可能会失败——innodb_log_checksums是从或假或0)。

当通用表空间与数据库的系统表空间具有相同的basename(通常ibdata1)，并与它存在于同一目录(通常是服务器的数据目录)。在相同情况下创建的压缩单文件备份将被损坏，并且无法恢复。为了避免这个问题，服务器管理员不应该将system表空间和具有相同basename的普通表空间放在同一个目录中;如果无法避免，则不要对数据库执行压缩备份。

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

如果任意一个数据库名称与任意一个undo表空间名称相同，则备份失败。为了备份成功，数据库管理员应该避免给任何数据库和undo表空间指定相同的名称(例如，使用默认的undo表空间名称)undo_001为数据库命名)，或者应该在备份之前重命名数据库。

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