数据库备份的重要性毋庸置疑，可以说，它是数据安全的最后一道防线。鉴于此，对于备份，我们通常会做以下要求：

多地部署对于核心数据库，我们通常有两地三中心的部署要求。对于备份来说，也是如此。一个备份应该有多个副本，每个副本存储在不同区域。
多介质部署一个备份的多个副本应存储在不同介质上，如磁盘和磁带，防止单一介质失效。
定期检查备份的有效性备份只是在做正确的事情，有没有把事情做对，还得依靠备份的有效性检查。

前两项，在条件允许的情况下，建议做。第三项必须做。

接下来，我们聊聊备份的相关话题，主要包括以下五方面的内容：

备份的常见分类。
MySQL中的备份工具。
mysqlbackup与mysqldump的备份恢复速度对比。
如何检测备份的有效性。
RTO和RPO 。

备份的常见分类

物理备份 VS 逻辑备份

物理备份，顾名思义，就是备份物理文件。其优缺点如下：

优点：

备份、恢复速度快。尤其是恢复速度，直接关系着数据库服务的RTO。
无需实例在线。在实例关闭的情况下，可直接拷贝文件，不用担心备份的一致性。关闭实例进行备份，也称之为 “冷备” 。

缺点：

备份文件大。
恢复时，对平台、操作系统、MySQL版本有要求，必须一致或兼容。
只能在本地发起备份。
因为是拷贝物理文件，即使文件中存在很多“空洞”（大量DELETE导致），也无法通过恢复来收缩。
对表的存储引擎有要求，无法备份MEMORY表。

逻辑备份，备份表的逻辑记录。其优缺点如下：

优点：

可移植性强。恢复时，对平台、操作系统、MySQL版本无要求。
灵活。尤其是在恢复时，可只恢复一个库或一张表。
对表的存储引擎没有要求，任何类型的表都可备份。
备份文件较小。
可远程发起备份。
恢复后，能有效收缩空间。

缺点：

备份、恢复速度慢。实际上，单论备份速度，多线程备份其实也不慢。但恢复速度呢，即使是多线程恢复，也很慢。
备份会"污染"Buffer Pool。业务热点数据会被备份数据驱逐出Buffer Pool 。

离线备份 VS 在线备份

离线备份，又可称之为 "冷备"，即实例关闭的情况下进行的备份。此时，只能进行物理备份，即全量拷贝物理文件。

在线备份，又可称之为 "热备"，即实例运行过程中进行的备份。此时，既可进行物理备份，又可进行逻辑备份。

因对业务侵入较小，线上一般使用在线备份。

全量备份 VS 增量备份

全量备份，即备份整个实例的全量数据。

增量备份，即只备份上次备份以来，那些发生了"变化"的数据。

通常来说，基于物理备份来实现增量备份较为简单，以MySQL为例，只需判断数据页的LSN是否发生了变化。

而对于逻辑备份，就很难实现，如常见的基于某个时间字段来进行增量备份，但其实，很难保证某个时间段之前的数据不被修改或删除。

MySQL中的备份工具

物理备份

物理备份相关的工具有：

XtraBackupPercona公司开源的备份工具，适用于MySQL、MariaDB、Percona Server。目前维护的大版本有两个：1. XtraBackup 2.4，适用于MySQL 5.6和5.7。2. XtraBackup 8.0。适用于 MySQL 8.0。之所以要维护两个版本，是因为MySQL 8.0中的redo log和数据字典的格式发生了变化。
mysqlbackupMySQL企业级备份工具（ MySQL Enterprise Backup ），适用于MySQL企业版。
Clone PluginMySQL 8.0.17引入的克隆插件。初衷是为了方便Group Replication添加新的节点。有了Clone Plugin，我们也能很方便的搭建一个从库，无需借助其它备份工具。

三者的实现原理基本相同，都是在备份的过程中，拷贝物理文件和redo log ，最后，再利用InnoDB Crash Recovery，将物理文件恢复到备份结束时的一致性状态。

逻辑备份

逻辑备份相关的工具有：

mysqldumpMySQL安装包自带的备份工具，单线程备份。
mydumper由Facebook、SkySQL、Oracle和Percona开发人员维护的一个多线程备份工具，可实现行级别的并行备份。
mysqlpumpMySQL 5.7引入的备份工具，可实现表级别的并行备份。
MySQL ShellMySQL Shell 8.0.21引入了一个工具-util.dumpInstance()，可实现行级别的并行备份。这个工具对备份实例和恢复实例的版本有要求：备份实例 >= 5.6，恢复实例 >= 5.7。
SELECT ... INTO OUTFILESQL命令，可将表记录直接导出到文件中。

下面说说这几个工具的异同点：

从实现原理来看，mysqldump、 mydumper、mysqlpump、 MySQL Shell可归为一类，本质上都是通过SELECT * FROM TABLE的方式备份数据，只不过在此基础上，通过全局读锁 + REPEATABLE READ事务隔离级别，实现了数据库的一致性备份。
SELECT ... INTO OUTFILE 充其量只是一个命令，算不上工具，更不用说数据库的一致性备份。
从导出的内容来看，mysqldump、mydumper、mysqlpump 会以INSERT语句的形式保存备份结果，如，INSERT INTO t1 VALUES (1,'aaa'),(2,'bbb'),(3,'ccc'); 而 MySQL Shell和SELECT ... INTO OUTFILE 是以CSV格式的形式保存备份结果，如，1 aaa
2 bbb3 ccc
在恢复，各个工具对应的恢复工具也不一样。具体来说，mysqldump、mysqlpump对应的恢复工具是mysql客户端，所以是单线程恢复。mydumper对应的恢复工具是myloader，支持多线程恢复。util.dumpInstance()对应的恢复工具是util.loadDump()，该工具实际调用的是LOAD DATA LOCAL INFILE命令，支持多线程恢复。SELECT ... INTO OUTFILE对应的恢复命令是LOAD DATA。

mysqlbackup VS mysqldump

下面是MySQL官方提供的一组数据，对比了mysqlbackup和mysqldump备份恢复时间。

第一张图比较的是备份时间，mysqldump是mysqlbackup的49倍。

第二张图比较的是恢复时间，mysqldump是mysqlbackup的80倍。

借此，我们也能看到逻辑备份工具相对于物理备份工具在备份、还原速度上的差距。

不过可惜的是，这里没有测试mydumper。

毕竟，针对数据量较大的实例，如果一定要使用逻辑备份，大家一般倾向于使用mydumper，而不是mysqldump。

如何检测备份的有效性

为什么要检测备份的有效性，原因主要有两个：

验证整个备份环节的可靠性。包括备份参数是否完备，备份集是否有效，备份介质是否损坏等。
通过检查备份的有效性，搭建一套完整的自动化恢复体系。很多时候，影响数据库恢复时间的并不是备份集太老，而是手动恢复过程中，因为命令、环境、流程的不熟悉，所带来的额外耗时。

如何检测备份的有效性，常用的方法有三个：

基于备份恢复实例，看实例能否起来。并在此基础上，进行随机查询。这种检测方法最简单。一般来说，实例能起来，且随机查询也没问题，就意味着这个备份集是可用的。但备份集可用，并不意味着这个备份集能满足我们的需求，譬如常见的，搭建从库。而且一些常见的问题，如备份中断、参数没指定准确，也无法通过这种方式检测出来。
在1的基础上，建立复制。如果从库在追主库的过程中，没有报错，大概率意味着主从数据是一致的。当然，也只是大概率，并不是100%。
在2的基础上，利用pt-table-checksum检查主从数据的一致性。如果检查结果没问题，则意味着主从数据是一致的，也就间接证明了备份的有效性。但因为pt-table-checksum在运行的过程中，会在chunk级别对表加S锁，对更新频繁的业务，还是有一定的影响。

一般来说，线上使用方法2足矣。

方法3，因为要检查主从数据的一致性，耗时相对较久，如果要检测的备份集很多，反而会影响检测的效率。

RTO 和 RPO

衡量一个数据中心的容灾能力时，有两个常用的指标：

RTO：Recovery Time Objective，恢复时间目标。指的是灾难发生后，必须在这个时间内恢复数据。在恢复数据的这段时间内，服务是不可用的，所以RTO也是服务可允许的最大不可用时间。如果我们要求服务的最大不可用时间是30分钟，那么RTO就是30分钟。RTO 越小，代表容灾系统的恢复能力越强。
RPO：Recovery Point Objective，数据恢复点目标。指的是灾难发生后，数据可以恢复到的时间点。譬如，我有一个系统，每天0点进行一次全备。当系统出现故障后，会基于上一次的备份来恢复。如果系统在凌晨3点出现故障，我们会丢失3个小时的数据。极端情况下，系统在23:59出现故障，我们会丢失24个小时的数据。这里的24小时就是这个系统的RPO 。RPO越小，代表系统越能保证数据的完整性。

RTO、RPO与灾难在时间轴上的关系如下图所示：

可以看到，RPO针对的是数据丢失，RTO针对的是服务宕机时间，两者之间没有必然的联系。

最理想的情况是RTO和RPO都为0，这就意味着当灾难发生时，系统会立即恢复，而且数据不会丢失。当然，RTO、RPO越小，需要投入的成本也越高。

具体到MySQL中，为了降低RTO和RPO，我们可以从以下几个方面着手：

RTO

增加备份频率，缩短备份周期。
选择物理备份，而不是逻辑备份。
添加延迟从库。
恢复流程的自动化。

RPO

增加备份频率，缩短备份周期。
搭建Binlog Server备份Binlog。当出现故障时，我们可以基于备份和Binlog做基于时间点的恢复。
添加延迟从库。

总结

从RTO的角度出发，应尽量选择物理备份，而不是逻辑备份。如果要使用逻辑备份，应尽量选择多线程备份工具和多线程恢复工具。

从RPO的角度出发，应尽量增加备份频率，缩短备份周期。

但 every coin has two sides，使用物理备份或者增加备份频率，无疑会增加存储成本。

所以，在确定备份策略和选择备份工具时，应从业务的RTO和RPO出发，结合存储成本综合考虑。

大多数公司会采取一个统一的备份策略，如一天一个全备。虽然灾难情况很少出现，开发和DBA童鞋也应充分理解到这里面的风险，并制定相应的预案及业务兜底方案。

另外，对于线上核心业务，如果只有备份，还是很难有效降低数据库服务的RTO和RPO，建议部署延迟从库。

如何选择MySQL的备份工具相关推荐

mysql企业备份工具(MEB)之mysqlbackup安装及使用
mysql enterprise版比community在备份工具上有了提升,多了一个mysqlbackup的工具,即mysql企业备份工具. 当然遵循GPL的社区版也可以用: 该工具单独下载: 到官方 ...
mysql 物理备份工具_mysql物理备份工具Xtrabackup安装配置
mysql物理备份工具Xtrabackup安装配置 1Xtrabackup工具介绍 Xtrabackup是一个对InnoDB做物理数据备份的工具,支持在线热备份(备份时不影响数据读写),是商业备份工具 ...
mysql物理备份工具Xtrabackup安装配置
mysql物理备份工具Xtrabackup安装配置 1 Xtrabackup工具介绍 Xtrabackup是一个对InnoDB做物理数据备份的工具,支持在线热备份(备份时不影响数据读写),是商业 ...
mysql远程备份工具_innobackupex实现MySQL远程备份
一.了解innobackupex 1.mysqldump mysql逻辑备份工具,作用于服务器本地,不需要额外安装插件可以单表备份,备份为sql文件形式.方便,在多个场景通用可通过shell命令实 ...
mysql自动备份工具_|Mysql自动备份工具(Auto MySQL Backup)下载v1.5 官方版附教程 - 欧普软件下载...
Auto MySQL Backup是一款好用的Mysql自动备份工具,可以对MySQL数据库进行每日.每周和每月备份,可同时备份多个数据库.压缩备份.备份远程数据和发送日志等,小编还带来了详细的使用方 ...
MySQL Study之--Mysql数据库备份工具（mysqldump）
MySQL Study之--Mysql数据库备份工具(mysqldump) 对于Mysql Database的备份方式有很多种,此次文档主要介绍mysqldump工具: mysqldump: ...
mysql的常用的备份工具_39、mysql常用备份工具
备份和恢复的作用 1.做灾难恢复 2.做审计 3.测试(备份数据做恢复测试) 备份类型: 根据备份时,数据库服务器是否在线冷备:cold backup 服务器处于离线状态温备:warm backu ...
perl 备份mysql_MySQLDumper：基于PHP和Perl的MySQL数据库备份工具
MySQL是在世界上最流行的数据库之一. 该数据库可以在微软Windows平台上安装除Linux平台的. 为什么这个数据库是如此受欢迎? 它可能由其强大的功能和免费使用. 作为数据库管理员,数据库备份 ...
mysql 查看备份工具_MariaDB/MySQL备份和恢复(一)：mysqldump工具用法详述【转】
本人博客搬家(本站无精力更新和维护):骏马金龙www.junmajinlong.com 1.备份分类按照是否能够继续提供服务,将数据库备份类型划分为: 热备份:在线备份,能读能写温备份:能读不能写 ...

如何选择MySQL的备份工具