在制定备份策略时，性能和存储空间是关键考虑因素。您希望备份快速完成，同时尽可能减少数据库服务器的 CPU 开销。您还希望备份数据紧凑，这样您就可以在手边保留多个备份，以便随时恢复。将备份数据传输到不同的系统应该既快捷又方便。在这样的考虑下，备份数据库的各种策略通常会给您带来不同的优势，因为您在选择特定策略时会做出不同的权衡。要选择最适合您需求的策略，您必须了解 MySQL Enterprise Backup 可以执行的每种备份的性质，
根据服务中断级别的备份种类
根据备份期间数据库操作的中断方式，备份分为 “热” 、 “暖”或“冷”：
非常低到低程度的中断：热 备份是在数据库运行时执行的备份。这种类型的备份不会阻止正常的数据库操作。它甚至可以捕获备份过程中发生的变化。与其他备份类型相比，它对数据库服务器造成的中断最少，并且当您希望避免应用程序、网站或 Web 服务脱机时，它是理想的备份选项。但是，在热备份能够被恢复之前，需要有一个额外的准备备份的过程，以使其保持一致（即正确反映数据库状态在备份完成时的状态）。看 第 5.1.7 节，“高级：准备和恢复目录备份”以获得更多解释。
当连接到正在运行的 MySQL 服务器时，MySQL Enterprise Backup 会对 InnoDB 表执行热备份。
中到高级别的中断：热 备份是在数据库处于只读状态下执行的备份。这种类型的备份会在备份过程中阻止对表的任何写入操作，但仍允许读取表。
当连接到正在运行的 MySQL 服务器时，MySQL Enterprise Backup 在使用热备份方法备份所有 InnoDB 表后，使用热备份 技术 备份所有 MyISAM 和其他非 InnoDB 表。因此，为了在热备份阶段备份尽可能多的数据，应该将InnoDB指定为新表的默认存储引擎（从MySQL 5.5开始默认设置），或者将现有表转换为使用InnoDB存储引擎.
高到非常高级别的中断： 冷备份是在数据库停止时创建的备份。它不仅对数据库服务造成最大的破坏，而且还使许多 MySQL Enterprise Backup 功能无法使用（例如，通过数据库连接自动检索有关数据库结构的信息的能力，因此不必通过配置文件或命令行选项提供给 MySQL Enterprise Backup）。
为避免服务中断，您通常会在副本上执行冷备份，无需关闭整个应用程序或网站即可停止。
根据是备份所有数据还是仅备份最近更改的备份种类
根据您是要将所有数据都包含到备份中还是只包含最近的更改，并根据最近的更改是从什么时候开始的，您可以执行完整备份、差异备份或增量备份。三种备份方式对CPU开销和磁盘空间的要求不同，适用于不同的情况：
A differential backup includes all changes to the data since the last full backup. It is faster than a full backup, saves storage space on the database server, and saves on network traffic when the backup is being transferred to a different server. However, it requires additional processing to make the backup ready for restore, which you can perform on a different system to minimize CPU overhead on the database server.
An Incremental backup includes all changes to the data since the last backup. It offers similar advantages over a full backup as a differential backup does, and often to a even greater extent by further decreasing the backup size. But it might also require more preparations on a longer series of backups, before a restore can be performed.
Compressed versus uncompressed backups
Backup compression saves you storage space and network traffic to transfer the backup data onto a different server. Compression does add some CPU overhead, but the overhead is algorithm dependent and it is fairly low for the default algorithm used by MySQL Enterprise Backup. Also, compression often reduces the IO overhead by a great deal, which might shorten the restore time, especially for slower IO devices. However, during the restore process, you need time for decompression and also storage space for both the compressed and decompressed data at the same time. So, take into account the additional storage space and the extra time needed during a restore when considering whether to create compressed backups.
将备份数据流式传输到另一台服务器时，您可能希望在原始服务器或目标服务器上压缩备份，具体取决于哪个服务器具有更多空闲 CPU 容量以及压缩可以节省多少网络流量。
有关涉及备份和恢复性能的技术和权衡的更多信息，请参阅第 11 章，MySQL 企业备份的性能注意事项。