以下是 mysqlbackup创建备份时执行的步骤的简要概述。它不包括 mysqlbackup采取的每一步，并且描述只代表一个非常一般的情况——这个过程可能看起来非常不同，这取决于您使用的备份选项（尤其是 第 20.10 节“性能/可伸缩性/容量选项”和 第 20.16 节，“特殊备份类型的选项”）。此说明仅适用于 MySQL Enterprise Backup 8.0.16 及更高版本。
通常，当您使用mysqlbackup运行备份操作时会发生这种情况：
InnoDB 数据文件、重做日志、二进制日志和中继日志文件（当前正在使用的日志文件除外）正在被复制到备份中，而数据库服务器照常运行。
在此期间，InnoDB 表的数据和结构可能发生了变化；因此，以下一些步骤用于确保在备份中捕获这些更改。
在 服务器实例上应用备份锁。它会阻止 InnoDB 表上的 DDL 操作（用户创建的临时表上的操作除外），但不会阻止 DML 操作（二进制日志未捕获的操作除外，例如对数据库的管理更改）。大多数对数据库的读写活动仍然被允许。应用此锁后， mysqlbackup扫描自第 1 步以来已被 DDL 操作修改的 InnoDB 表，并相应地对备份进行更改。
一条 语句应用于所有非 InnoDB 表（对于 8.0.18 及更高版本，仅适用于要包含在备份中的非 InnoDB 表），之后复制与备份相关的任何非 InnoDB 表。
FLUSH TABLEStbl_name [, tbl_name]... WITH READ LOCK如果数据库中不存在用户创建的非 InnoDB 表，则跳过此步骤。
对服务器上的日志记录活动进行了短暂的阻止，以便mysqlbackup收集与日志记录相关的信息，如当前 InnoDB LSN、二进制日志位置、GTID、复制源或副本状态等。
释放非 InnoDB 表上的读锁。
使用上述步骤 4 中的信息，复制当前正在使用的二进制或中继日志文件的相关部分。这确保了自第 1 步以来对 InnoDB 表的所有最近更改都在备份中被捕获，因此它们可以稍后应用于原始备份 数据以使恢复的服务器处于一致状态。
服务器实例上的备份锁被释放。数据库现在恢复正常操作。
复制或创建之前尚未复制的重做日志文件，以及备份的所有元数据文件。
备份操作完成， mysqlbackup返回成功。