2.1.关闭MySQL做备份是最简单、最安全的
2.2.所有获取一致性副本的方法中最好的
2.3.损坏或不一致的风险最小
2.4.根本不用关心InnoDB缓冲池中的脏页或其他缓存
2.5.不需要担心数据在尝试备份的过程中被修改
2.5.1.服务器不对应用提供访问
3.备份时间3.1.将备份复制到目的地需要多久
4.备份负载4.1.在将备份复制到目的地时对服务器性能的影响有多大
4.2.在备份服务器上压缩而不是在MySQL服务器上
4.3.PrconaXtraBackup和MySQLEntrprisBackup这样的工具都有限流选项，可在使用pv时加--rat-limit选项来限制备份脚本的吞吐量
5.牺牲其一以增强另外一个6.恢复时间6.1.把备份镜像从存储位置复制到MySQL服务器、重放二进制日志等，需要多久
7.逻辑备份7.1.导出
7.2.以一种MySQL能够解析的格式来包含数据
7.2.1.SQL语句
7.2.2.以某个符号分隔的文本
7.3.优点
7.3.1.逻辑备份备份的文件是可以用编辑器或像grp和sd之类的命令查看和操作的普通文件
7.3.2.恢复非常简单
7.3.3.可以通过网络来备份和恢复，也就是说，可以在与MySQL主机不同的另外一台机器上操作
7.3.4.可以在类似云数据库这样不能访问底层文件系统的系统中使用
7.3.5.灵活
7.3.6.与存储引擎无关
7.3.6.1.消除了底层数据存储引擎的差异
7.3.7.有助于避免数据损坏
7.3.7.1.如果MySQL在内存中的数据还没有损坏，当不能得到一个正常的裸文件备份时，或许可以得到一个可以信赖的逻辑备份
7.4.缺点
7.4.1.必须由数据库服务器完成生成逻辑备份的工作，因此要占用更多的CPU周期
7.4.1.1.某些场景下比数据库文件本身更大
7.4.2.无法保证导出后再还原出来的一定是同样的数据
7.4.2.1.浮点表示的问题、软件Bug等都会导致问题
7.4.3.从逻辑备份中还原需要MySQL加载和解释语句，将它们转化为存储格式，并重建索引，所有这一切会很慢
7.4.3.1.MySQL中导出数据和通过SQL语句将其加载回去的庞大开销
7.4.3.2.如果使用逻辑备份，测试恢复需要的时间将非常重要
7.4.3.3.逻辑备份最可怕的地方就是不确定的还原时间
8.裸文件备份8.1.原始文件是指存放于硬盘上的文件
8.2.直接复制原始文件
8.3.优点
8.3.1.基于文件的物理备份，它只需将需要的文件复制到其他地方即可完成备份，不需要其他额外的工作来生成原始文件
8.3.2.非常容易跨平台、操作系统和MySQL版本工作
8.3.3.从裸文件备份中恢复会更快
8.3.3.1.MySQL服务器不需要执行任何SQL语句或构建索引
8.3.3.2.如果有很大的InnoDB表，无法完全缓存到内存中，则裸文件备份的恢复要快得多
8.3.3.2.1.至少要快一个数量级
8.4.缺点
8.4.1.InnoDB的原始文件通常比相应的逻辑备份要大得多
8.4.1.1.表空间往往包含很多未使用的空间
8.4.2.不总是可以跨平台、操作系统及MySQL版本的
8.4.2.1.文件名大小写敏感和浮点格式是可能会遇到麻烦的
8.4.2.2.对于需要长期保留或者是用于满足法律合规要求的备份，尽量不要完全依赖裸文件备份
8.4.2.3.每隔一段时间需要做一次逻辑备份
8.4.3.除非经过测试，不要假定备份（特别是裸文件备份）是正常的
8.4.3.1.CHECKTABLES
8.4.3.2.不建议仅对文件运行innochcksum
9.混合使用9.1.使用裸文件备份
9.2.用得到的数据启动MySQL服务器实例并运行mysqlchck
9.3.周期性地使用mysqldump执行逻辑备份
9.4.优点是不会使生产服务器在导出时有过度负担
9.5.如果能够方便地利用文件系统的快照，也可以生成一个快照，将该快照复制到另外一台服务器上并释放，然后测试原始文件，再执行逻辑备份
10.备份什么10.1.恢复的需求决定需要备份什么
10.2.最简单的策略是只备份数据和表定义，但这是一个最低的要求
10.3.非显著数据
10.3.1.二进制日志和InnoDB事务日志
10.3.2.在理想情况下，应该把整个数据目录和MySQL一起备份起来
10.4.代码
10.4.1.现代的MySQL服务器可以存储许多代码，例如，触发器和存储过程
10.4.2.实际是存放在mysql数据库中的
10.5.服务器配置
10.5.1.对于服务器配置来说，备份中对生产服务器至关重要的任何外部配置，都十分重要
10.6.选定的操作系统文件
10.6.1.在UNIX服务器上，这可能包括cron任务、用户和组的配置、管理脚本，以及sudo规则
11.部分备份11.1.一般不包含完整的数据集
11.1.1.因为某些数据没有改变
11.1.2.对减少服务器开销、备份时间及备份空间而言都很适合
11.2.PrconaXtraBackup和MySQLEntrprisBackup，仍然会扫描服务器上的所有数据块，因而并不会节约太多的开销
11.2.1.确实会减少一定量的备份时间和大量用于压缩的CPU时间
11.2.2.会减少磁盘空间的使用
11.3.差异备份
11.3.1.自上次全备份后所有改变的部分而做的备份
11.4.增量备份
11.4.1.对自任意类型的上次备份后的所有修改做的备份
11.4.2.缺点
11.4.2.1.会增加恢复的复杂性
11.4.2.2.额外的风险
11.4.2.3.更长的恢复时间
12.建议12.1.使用PrconaXtraBackup和MySQLEntrprisBackup中的增量备份特性
12.2.备份二进制日志
12.2.1.在每次备份后使用FLUSHLOGS来开始记录一个新的二进制日志，这样就只需要备份新的二进制日志
12.3.如果有一些“引用”表，例如，包含不同语种、各个月的名称列表，或者州或区域的简写等，可以考虑将它们单独放在一个数据库中，这样就不需要每次都备份这些表
12.3.1.一个更好的选择可能是把这些数据放到程序代码中，而不是保存在数据库中
12.4.某些数据根本不需要备份
12.4.1.相对于从全备份中可能获得的快速恢复时间，避免备份可以节约更多时间开销
12.4.2.临时数据也不用备份
12.5.备份所有的数据，然后发送到一个有去重特性的地方
12.6.如果可以做全备份，考虑到简便性，建议尽量做全备份
12.6.1.建议至少一周一次
13.复制13.1.从副本中备份最大的好处是可以不干扰源库，避免在源库上增加额外的负载
13.1.1.这是一个建立副本服务器的好理由，即使不需要用它做负载均衡或提供高可用性
13.2.用GTID是非常明智的
13.2.1.避免了必须保存有关复制过程的所有信息
13.3.故意将一个副本延迟复制一段时间对于某些灾难场景非常有用
13.4.源库与副本数据不匹配是很常见的，并且MySQL没有方法检测这个问题
13.4.1.唯一方法是使用PrconaToolkit中的pt-tabl-chcksum之类的工具
13.4.2.防止这种情况的最好方法是使用supr_rad_only来确保只有复制可以写入副本
13.5.复制不是备份