1. 在线备份

2. 离线备份

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. Percona XtraBackup和MySQL Enterprise Backup这样的工具都有限流选项，可在使用p v时加--rate-limit选项来限制备份脚本的吞吐量

5. 牺牲其一以增强另外一个

6. 恢复时间

6.1. 把备份镜像从存储位置复制到MySQL服务器、重放二进制日志等，需要多久

7. 逻辑备份

7.1. 导出

7.2. 以一种MySQL能够解析的格式来包含数据

7.2.1. SQL语句

7.2.2. 以某个符号分隔的文本

7.3. 优点

7.3.1. 逻辑备份备份的文件是可以用编辑器或像grep和sed之类的命令查看和操作的普通文件

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. CHECK TABLES

8.4.3.2. 不建议仅对文件运行innochecksum

9. 混合使用

9.1. 使用裸文件备份

9.2. 用得到的数据启动MySQL服务器实例并运行mysqlcheck

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. Percona XtraBackup和MySQL Enterprise Backup，仍然会扫描服务器上的所有数据块，因而并不会节约太多的开销

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. 使用Percona XtraBackup和MySQL Enterprise Backup中的增量备份特性

12.2. 备份二进制日志

12.2.1. 在每次备份后使用FLUSH LOGS来开始记录一个新的二进制日志，这样就只需要备份新的二进制日志

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. 唯一方法是使用Percona Toolkit中的pt-table-checksum之类的工具

13.4.2. 防止这种情况的最好方法是使用super_read_only来确保只有复制可以写入副本

13.5. 复制不是备份