1、简介

数据无价，MySQL作为一个数据库系统，其备份自然也是非常重要且有必要去做。备份的理由千千万，预防故障，安全需求，回滚，审计，删了又改的需求等等，备份的重要性不言而喻。除了备份本身，如何使用备份来恢复服务也是一项重点内容，不能用来恢复的备份没有意义。本文主要会针对备份和恢复这两方面做一些简单的介绍。

本文为《高性能MySQL》备份相关章节的读书笔记。

2、备份和恢复的简单定义

正如简介所说，备份人尽皆知，也很容易引起人的重视。根据需求写定期脚本，或者使用其他方式都是比较常见的。但是恢复就没有那么引人注目了。比如说，也许会每周/每天定期进行自动备份。但是多久会进行一次备份的恢复测试？备份的内容是否完成？是否可用于恢复？如果出现故障，恢复的流程是否易操作？
备份只是数据源，如何使用数据源，彻底恢复系统这个过程。也非常重要。备份与恢复，都是MySQL运维中需要掌握的内容。

备份的意义在于恢复。如果不能恢复，那就不叫备份（比如RAID阵列不是备份，如果DROP DATABASE，RAID阵列不能恢复）

[还原] 和 [恢复] 的区别：

• 还原：仅指将备份文件中的内容提取出来并加载。
• 恢复：包括还原备份文件在内的一系列措施，目的是让服务恢复正常运行，比如重启MySQL，修改配置等其他操作。

也就是说，恢复是要恢复到异常出前，采取的所有操作(比如修改参数，重启服务等)。不仅仅只是还原备份。

3、恢复计划需要考虑的几个因素

恢复计划在设计的时候，需要考虑一些因素，从而根据不同的需求进行更好的规划。可以根据RPO(恢复点目标)和RTO(恢复时间目标)这两个需求来协助制定合适的恢复策略。

• RPO(恢复点目标)：可以容忍丢失多少数据？(需要恢复所有数据，还是能容忍上一次备份以来的数据丢失？)
• RTO(恢复时间目标)：需要等待多久将数据恢复？(用户能接受到什么程度)

也许还需考虑：需要恢复什么？(整个服务器，单个库，单个表，还是事务)

其次，恢复计划需要定期进行测试，抽出数据测试备份确实有效、实际进行一次完整的备份恢复，熟悉整个恢复流程，确保真正发生问题时，可以有条不紊的完成恢复。

4、备份

4.1、备份内容包括什么？

最简单的策略就是只备份数据和表定义。但是恢复数据库需要更多内容，如果能备份的越充足，那么恢复起来也就更容易。（主要还是根据需求）

比如可以根据实际情况，考虑备份如下内容：
1、Binlog和InnoDB事务日志。
2、主/从库配置文件。
3、数据库操作系统配置(cron、脚本、内核参数)

或者说，根据需要进行备份内容的扩展。如果对于数据库恢复、甚至重建有很高需求(比如要求更快恢复)，那么备份更多的内容也必不可少。如果需要有从0恢复数据库的能力，那需要做更多工作。

4.2、物理备份与逻辑备份

物理备份和逻辑备份的一点抉择：

• 对于大数据库，必须有物理备份。逻辑备份太慢，也可考虑基于快照的备份做辅助。
• 对于小数据库，逻辑备份几乎就可以了。

物理备份简单高效，逻辑备份尽量也要做。【两者都要有，看具体需求和资源分配】
其次：除非经过测试，否则不能假设备份可用。比如使用mysqlcheck -A 测试数据库。

4.3、Binlog备份

Binlog也是备份中的重要一环，因为基于时间点的恢复需要用到它。而且Binlog一般很小，频繁的备份也较容易实现。如果有某个时间点的数据备份，加上自那以后的所有Binlog，就可以回滚所有变动。

4.3.1、备份Binlog的一些策略

• 建议expire_logs_days设置的尽量长，至少超过2次最近的全备份。
• 备份Binlog时，可以使用FLUSH LOGS创建新的Binlog（这样就只需要备份最新的Binlog了） 
• 可以考虑将数据和Binlog分开保存，避免同时丢失。
• 可以选择经常备份Binlog或者配置一个 --log_slave_updata的只读备库。

需要注意的是，expire_log_days是通过日志文件的修改时间来判断的，而不是内容。（如果一直只有一个Binlog文件，可能就不会清理）。所以一定要使用FLUSH LOGS定期刷新Binlog。

4.3.2、老Binlog的清理
最好使用expire_log_days来进行自动的清理，保留一定天数。如果需要用cron清理。那么不要使用 find+rm配置的cron清理日志。
0 3 * * * /usr/bin/mysql /var/log/mysql -mtime +N -name "mysql-bin.[0-9]"* | xargs rm
使用如下cron代替：
0 3 * * * /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"

4.3.3、Binlog备份的几点注意事项

• 增长保存时间只是一种配置，不代表Binlog本身就不需要备份。Binlog仍然需要定期备份，以便可以结合最近的备份使用。
• 需要注意的是，从库也使用Binlog。所以需要区分从库和备份的Binlog管理。

4.4、增量备份与差异备份

增量备份：自任意类型备份后，改动的所有内容的备份。
差异备份：特指自上次全备份之后，改动的所有内容的备份。

也就是说，差异备份基于全备份。而增量备份基于任意备份(比如某一个指定的差异备份。
下面举一个例子：周日进行一次全备份，周一针对周日的全备份做一次差异备份。周二开始就可以有两种选择：1、基于周日的全备份做备份(差异)。2、基于周一的差异备份做备份(增量)

差异备份可选项：

• 不要备份没有改变的表。
• 不要备份没有改变的行

虽然这样做差异备份可以提高恢复速度。但是全备份还是很有必要的。(全备份可以频率低，但是必须有)。

4.5、从库备份

在从库中备份，有时候是一个可选项，不会干扰到主库，避免给主库增加更多的负载。其次，当计划从从库备份的时候，要保存更多信息，比如从库相对于主库的位置(偏移)等。

首先从库不等于备份，从库和主库数据不匹配是很常见的。其次、从从库备份确实可以减轻主库备份时的负载，但是不够好。稳定起见，还是建议进行主库备份、全备份。

4.6、其他注意事项

4.6.1、在线备份与离线备份
离线备份是最简单最安全的。也是一致性最好的。问题就是，大部分数据库不能接受停机备份。所以基本还是用在线备份，或者说不停机备份

可以考虑在业务低峰期进行在线备份，即使负载增大也不会有太大影响。

4.6.2、数据一致性
数据一致性：对于多个表之间数据的一致性要求。（比如两个逻辑相关的操作分在了两个事务内，而备份在两个事务之间执行，就会导致数据不一致）
InnoDB可以在转储一组相关表的时候，开始一个事务，这样可以很大程度上保证数据的一致性。

但是也要注意，如果事务设置的不合理，比如一组相关表的修改分在了两个事务内，这仍然会导致数据不一致。（一组表的相关操作需要确保在一个事务内)

4.6.3、定期进行备份恢复测试，确认整个恢复过程需要的资源
能恢复的备份才有价值，不是有备份就可以

小结

本文讲解了一些备份的基本知识和概念，包括一些基本概念、恢复的重要性、备份和恢复的简单策略。还提及到了备份内容的选择、差异/增量备份、Binlog备份等。后续还需要继续学习，了解备份和恢复的具体操作方法和实践。