Mysql 完整备份：-
https://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/mysqlbackup.full.html
命令行或配置文件中的选项？
为清楚起见，本手册中的示例通常显示一些
与 mysqlbackup 命令一起使用的命令行选项。为了
方便性和一致性，您可以包括那些保留的选项
大多数备份作业未更改到 [mysqlbackup] 部分
您提供给 mysqlbackup 的 MySQL 配置文件。 mysql备份
如果它们是，还从 [mysqld] 部分中选择选项
在那里。将选项放入配置文件可以
为您简化备份管理：例如，将端口
信息写入配置文件，可以避免需要编辑
每次数据库实例切换到
不同的端口。请参阅第 14 章，配置文件和参数
配置文件的使用细节。
在单个目录或时间戳子目录中输出？
为方便起见， --with-timestamp 选项创建唯一命名的
备份目录下的子目录来保存每个文件的输出
备份工作。带时间戳的子目录使其更容易
建立保留期限，以便轻松删除和归档
备份已超过一定年龄的数据。
如果您确实使用单个备份目录（也就是说，如果您省略
--with-timestamp 选项），或者为每个备份作业指定一个新的唯一目录名称，或者指定 --force 选项以覆盖
现有的备份文件。
对于使用 --incremental-base 选项的增量备份
指定包含先前备份的目录，以使
目录名称可预测，您可能不喜欢使用
--with-timestamp 选项并使用您的备份脚本生成一系列目录名称。
始终完全备份，还是完全备份加增量备份？
如果您的 InnoDB 数据量很小，或者您的数据库非常繁忙
备份之间有很大比例的数据更改，您可能想要
每次运行完整备份。但是，您通常可以节省时间和
通过运行定期完整备份，然后多次运行存储空间
它们之间的增量备份，如第 4.3.2 节所述，
“进行差异或增量备份”。
是否使用压缩？
创建压缩备份可以为您节省大量存储空间
并显着减少 I/O 使用量。并使用 LZ4 压缩
方法（自 3.10 版起引入），处理的开销
压缩率很低。如果数据库备份正在移动
从活动数据库文件所在的更快的磁盘系统到
可能存储速度较慢，压缩通常会显着降低
整体备份时间。它可以减少恢复时间，因为
好。一般来说，我们推荐 LZ4 压缩而不是不压缩
大多数用户，因为基于 LZ4 的备份通常会在更短的时间内完成
时期。但是，在您的内部测试 MySQL Enterprise Backup
环境来确定什么是最有效的方法。
增量备份功能主要用于 InnoDB 表或只读或很少更新的非 InnoDB 表。对于非 InnoDB 文件，如果该文件自上次备份后发生更改，则整个文件将包含在增量备份中。
您不能使用 --compress 选项执行增量备份。
增量备份检测 InnoDB 数据文件中页面级别的更改，而不是表行；备份每个已更改的页面。因此，节省的空间和时间与更改的 InnoDB 行或列的百分比并不完全成正比。
当删除 InnoDB 表并执行后续增量备份时，应用日志步骤会从完整备份目录中删除相应的 .ibd 文件。由于备份程序无法对非 InnoDB 文件的用途具有相同的洞察力，因此当在完整备份和后续增量备份之间删除非 InnoDB 文件时，应用日志步骤不会从完整备份目录。因此，恢复备份可能会导致已删除的文件重新出现。
仅使用重做日志创建增量备份
--incremental-with-redo-log-only 可能比
用于创建增量备份的 --incremental 选项：
对 InnoDB 表的更改是根据以下内容确定的
InnoDB 重做日志。由于重做日志文件具有固定大小
你提前知道，它可以需要更少的 I/O 来读取更改
它们比扫描 InnoDB 表空间文件以找到更改的
页面，取决于数据库的大小、DML 活动的数量、
和重做日志文件的大小。
由于重做日志文件充当循环缓冲区，记录
当新的 DML 操作发生时，旧的更改被覆盖，您
必须按照规定的可预测时间表进行新的增量备份
根据日志文件的大小和生成的重做数据量
你的工作量。否则，重做日志可能无法回溯到足够远的地方
记录自上次增量备份以来的所有更改，在
在这种情况下mysqlbackup会很快确定它不能继续
并将返回错误。您的备份脚本应该能够捕获
该错误，然后使用
--incremental 选项。
例如：
要计算重做日志的大小，请发出命令 SHOW
VARIABLES LIKE 'innodb_log_file%' 并根据输出相乘
innodb_log_file_size 设置的值
innodb_log_files_in_group。计算重做日志大小
物理层，查看 MySQL 实例的 datadir 目录
并总结与模式 ib_logfile* 匹配的文件的大小。
InnoDB LSN 值对应于写入的字节数
重做日志。要在某个时间点检查 LSN，请发出命令
SHOW ENGINE INNODB STATUS 并在 LOG 标题下查看。尽管
计划您的备份策略，定期记录 LSN 值并
从当前值中减去较早的值以计算出多少
每小时、每天等都会生成重做数据。
在 MySQL 5.5 之前，保留重做日志是常见的做法
相当小，以避免 MySQL 服务器启动时间过长
杀死而不是正常关闭。在 MySQL 5.5 及更高版本中，
崩溃恢复的性能显着提高，如前所述
在优化 InnoDB 配置变量中，以便您可以使
如果这有助于您的备份策略和您的
数据库工作负载。
这种类型的增量备份不能容忍太低
--start-lsn 值作为标准 --incremental 选项。例如，您不能先进行完整备份，然后再进行一系列
--incremental-with-redo-log-only 备份都使用相同的 --start-lsn 值。确保将上一次备份的精确结束LSN指定为下一次增量备份的开始LSN；做
不要使用任意值。
注意确保 LSN 值在连续的
增量备份，建议您始终使用
使用 --incremental-with-redo-log-only 选项时的 --incremental-base 选项。
判断这种增量备份是否实用，
对特定的 MySQL 实例有效：
衡量 InnoDB 重做日志文件中数据更改的速度。
定期检查 LSN 以确定累积了多少重做数据
在几个小时或几天的过程中。
比较redo log的积累率和redo的大小
日志文件。使用此比率查看增量的频率
备份，以避免备份失败的可能性，因为
历史数据在重做日志中不可用。例如，如果
您每天产生 1GB 的重做日志数据，并且总大小
您的重做日志文件为 7GB，您将安排增量备份
每周一次以上。您可能会执行增量
每隔一两天备份一次，以避免突然出现潜在问题
一连串的更新带来了比平时更多的重做。
使用 --incremental 和
--incremental-with-redo-log-only 选项，用于确认重做日志备份技术是否比
传统的增量备份方法。结果可能取决于
数据的大小、DML 活动的数量以及
重做日志文件。在具有真实数据的服务器上进行测试
量和实际工作量。例如，如果你有大量的重做
日志文件，在增量备份过程中读取它们可以
使用传统的读取 InnoDB 数据文件所需的时间
增量技术。相反，如果您的数据量很大，
读取所有数据文件以找到少数更改的页面可能会更少
比处理更小的重做日志文件更有效。
增量备份的其他注意事项
增量备份功能主要用于 InnoDB
表，或只读或很少更新的非 InnoDB 表。
增量备份检测 InnoDB 中页面级别的更改
数据文件，而不是表行；改变的每一页都是
备份。因此，空间和时间节省并不完全
与更改的 InnoDB 行或列的百分比成正比。
对于非 InnoDB 文件，整个文件都包含在增量文件中
如果该文件自上次备份以来已更改，则备份，这意味着
比较时，备份资源的节省不太显着
以 InnoDB 表为例。
您不能使用 --compress 选项执行增量备份。
基于备份（完整或
增量）使用 --no-locking 选项创建，使用
--skip-binlog 选项跳过二进制日志的备份，因为二进制日志信息将无法用于 mysqlbackup
情况。
增量备份示例
本示例使用 mysqlbackup 对 MySQL 服务器进行增量备份，包括所有数据库和表。我们展示了两种选择，一种使用 --incremental-base 选项，另一种使用 --start-lsn 选项。
使用 --incremental-base 选项，您不必在一次备份和下一次备份之间跟踪 LSN 值。相反，您可以只指定前一个备份的目录（完整或增量），mysqlbackup 根据前一个备份的元数据找出此备份的起点。因为您需要一组已知的目录名称，所以您可能希望使用硬编码名称或在自己的备份脚本中生成一系列名称，而不是使用 --with-timestamp 选项。
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--incremental-base=dir:/incr-backup/wednesday \
--incremental-backup-dir=/incr-backup/thursday \
backup
...多行输出...
mysqlbackup：在目录“/incr-backup/thursday”中创建的备份
mysqlbackup：start_lsn：2654255717
mysqlbackup：incremental_base_lsn：2666733462
mysqlbackup: end_lsn: 2666736714z
101208 17:14:58 mysqlbackup：mysqlbackup完成OK！
请注意，如果您的上一次备份是单个文件而不是目录备份，您仍然可以通过为 dir:directory_path 指定您在备份过程中使用 --backup-dir 选项提供的临时目录的位置来使用 --incremental-base完整备份。
作为指定 --incremental-base=dir:directory_path 的替代方法，您可以使用 --incremental-base=history 告诉 mysqlbackup 从服务器上的 backup_history 表中记录的上次成功备份中查询 end_lsn 值： last_backup（这要求上次备份是在连接到服务器的 mysqlbackup 时进行的）。
您还可以使用 --start-lsn 选项来指定增量备份应该从哪里开始。你必须在备份结束时记录mysqlbackup报告的上一次备份的LSN：
mysqlbackup：能够解析日志到 lsn 2654255716
该编号也记录在备份期间 --backup-dir 指定的文件夹中的 meta/backup_variables.txt 文件中。然后使用 --start-lsn 选项将该号码提供给 mysqlbackup。然后，增量备份包括在指定 LSN 之后发生的所有更改。既然上一次备份的位置不是很重要，你可以使用--with-timestamp自动创建命名子目录。
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--start-lsn=2654255716 \
--with-timestamp \
--incremental-backup-dir=/incr-backup \
backup
...多行输出...
mysqlbackup：在目录“/incr-backup/2010-12-08_17-14-48”中创建的备份
mysqlbackup：start_lsn：2654255717
mysqlbackup：incremental_base_lsn：2666733462
mysqlbackup: end_lsn: 2666736714
101208 17:14:58 mysqlbackup：mysqlbackup完成OK！
要创建增量备份映像，请使用以下命令，使用 --incremental-backup-dir 指定一个临时目录，用于存储备份的元数据和一些临时文件：
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--start-lsn=2654255716 \
--with-timestamp \
--incremental-backup-dir=/incr-tmp \
--backup-image=/incr-backup/incremental_image.bi
backup-to-image
但在以下示例中，由于 --backup-image 未提供要创建的映像文件的完整路径，因此在 --incremental-backup-dir 指定的文件夹下创建增量备份映像：
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--start-lsn=2654255716 \
--with-timestamp \
--incremental-backup-dir=/incr-images \
--backup-image=incremental_image1.bi
backup-to-image
https://dev.mysql.com/doc/mysql-enterprise-backup/3.7/en/mysqlbackup.incremental.html