数据备份的重要性

数据备份是为了尽可能快地全盘恢复运行计算机系统所需的数据和系统信息，它不仅在网络系统硬件故障或人为失误时起到保护作用，同时能在集群环境下失效切换之后备机能够正常接管关键业务的基础。当然，数据备份也是系统灾难恢复的前提之一。

造成数据丢失的原因

程序错误
人为错误
计算机失败
磁盘失败
灾难和偷窃

数据库备份的分类

1、物理备份

物理备份是磁盘块为基本单位将数据从主机复制到备机，对数据库操作系统的物理文件(如数据文件，日志文件等)的备份。
物理备份是位于文件系统之下和硬件磁盘驱动之上。增加了一个软驱动，它忽略了文件和结构，处理过程简洁，因此在执行过程中所花费在搜索操作上的开销较少，备份的性能很高。
物理备份避免了当文件出现一个小的改动的时候，就需要对整个文件做备份，只是会去做改动部分的备份，有效的提高了备份效率，节省了备份时间。
物理备份可以做到高效的实时备份，因为在每次主机往磁盘写数据的时候，都需要同时将数据写入到备机，这种写入操作都是基于磁盘扇区的，所以，很快就能被识别。只有在备机完成之后，才会返回给上层的应用系统来继续下一步工作。
物理备份是在文件系统之下对数据进行复制，所以它不受文件系统限制，可以支持各种文件系统包括RAW分区。

2、逻辑备份

逻辑备份是以文件为基本单位将数据从主机复制到备机，对数据库逻辑组件（如表等数据库对象）的备份。
逻辑备份是基于文件级别的备份，由于每个文件都是由不同的逻辑块组成。每一个逻辑的文件块存储在连续的物理磁盘块上，但组成一个文件的不同逻辑块极有可能存储在分散的磁盘块上。逻辑备份在对非连续存储磁盘上的文件进行备份时需要额外的查找操作。这些额外的操作增加了磁盘的开销，降低了磁盘的吞吐率。所以，跟物理备份相比较，备份性能较差。
逻辑备份是很难做到实时备份的，因为它的每次修改都是基于文件的，而文件的哪部分被修改，系统很难实时捕获到，所以备份的时候需要把整个文件读一遍再发到备机，实时的效率不是很高。
逻辑备份是以单个文件为单位对数据进行复制，所以它受文件系统限制，仅能对部分支持的文件系统做备份，不支持RAW分区。
逻辑备份模式下，文件即使一个很小的改变，也需将整个文件备份。这样如果一个文件很大的情况下，就会大幅度的降低备份效率，增加磁盘开销和备份时间。

从数据库的备份策略角度，备份可分为：
全量备份：每次对数据进行完整的备份
差异备份：备份那些自从上次完全备份之后被修改过的文件
增量备份：只有那些在上次完全备份或者增量备份后被修改的文件才会被备份

2.1、全量备份

全量备份就是指对某一个时间点上的所有数据或应用进行的一个完全拷贝。实际应用中就是对整个系统进行全量备份，包括其中的系统和所有数据。
优点：
只要用一个全量数据就可以恢复丢失的数据。因此大大加快了系统或数据的恢复时间。
缺点：
各个全备份磁带中的备份数据存在大量的重复信息；另外，由于每次需要备份的数据量相当大，因此备份所需时间较长。

2.1.1、全量备份的流程

先创建相应目录
使用mysqldump进行全量备份
对备份文件进行压缩
使用scp复制备份文件到其他服务器
清理过期的全量备份文件
定时任务自动进行全量备份

2.1.2、全量备份恢复命令

全量备份命令

#备份数据库实例中数据库的某个表
mysqldump -uusername -ppasswd --quick --events --flush-logs --delete-master-logs --single-transaction test student > filename.sql
#备份数据库实例中多个数据库
mysqldump -uusername -ppasswd --quick --events --flush-logs --delete-master-logs --single-transaction --databases dbname1 dbname2 ... > filename.sql
#备份数据库实例中所有数据库
mysqldump -uusername -ppasswd --quick --events --all-databases --flush-logs --delete-master-logs --single-transaction > filename.sql

全量备份恢复命令

#恢复某个库中的数据
mysql -u username -P [dbname] < filename.sql
#恢复数据库实例中所有数据
mysql -u root -p < /data/mysql/all.sql

2.2、差异备份

差异备份与增量备份一样，都只备份变动过的数据。但差异备份是累积的，一个档案只要自上次完整备份后，曾被更新过，那么接下来每次做差异备份时，这个档案都会被备份。这表示差异备份中的档案，都是自上次完全备份之后，曾被改变的档案。如果要复原整个系统，那么您只要先复原完全备份，再复原最后一次的差异备份即可。增量备份是针对于上一次备份（无论是哪种备份）：备份上一次备份后，所有发生变化的文件。所以，差异备份的大小，会随着时间过去而不断增加（假设在完全备份间，每天修改的档案都不一样）。以备份空间与速度来说，差异备份介于增量备份与完全备份之间；但不管是复原一个档案或是整个系统，速度通常比完全备份、增量备份快（因为要搜寻/复原的磁盘数目比较少）。

2.3、增量备份

增量备份是指在一次全备份或上一次增量备份后，以后每次的备份只需备份与前一次相比增加和者被修改的文件。这就意味着，第一次增量备份的对象是进行全备后所产生的增加和修改的文件；第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件，如此类推。
二进制日志保存了所有更新或者可能更新数据的操作，二进制日志在启动MySQL服务器后开始记录，并在文件达到所设大小或者收到flush logs 命令后重新创建新的日志文件，只需定时执行flush logs 方法重新创建新的日志，生成二进制文件序列，并及时把这些文件保存到一个安全的地方，即完成了一个时间段的增量备份。

优点：
没有重复的备份数据，因此备份的数据量不大，备份所需的时间很短。
缺点：
增量备份的数据恢复是比较麻烦的。您必须具有上一次全备份和所有增量备份（一旦丢失或损坏其中的一个增量备份，就会造成恢复的失败），并且它们必须沿着从全备份到依次增量备份的时间顺序逐个反推恢复，因此这就极大地延长了恢复时间。

2.3.1、增量备份的流程

开启log_bin

若没开启log_bin，则修改mysql配置文件my.cnf，添加以下配置，重启mysql使配置生效

log-bin=/var/lib/mysql/mysql-bin
刷新日志
遍历日志索引文件
备份新日志文件，忽略已经备份的文件

2.3.2、恢复增量备份数据

常用的增量恢复的方法有三种：一般恢复、基于位置的恢复、基于时间点的恢复。

对二进制日志文件进行解码
在我们对binlog日志操作的时候，我们需要先对binlog日志进行解码。

mysqlbinlog --no-defaults mysqld-bin.000001 > opt/bk01.txt    ##将二进制文件追加到/opt目录下

一般恢复

将所有备份的二进制日志内容全部恢复。

mysqlbinlog[--no-defaults] 增量备份文件 |mysql-u 用户名 -p 密码

基于位置的恢复

数据库管理员在操作数据库时可能在同一时间点既有错误的操作也有正确的操作，通过基于位置进行恢复可以更加精准

# 基于位置的恢复格式--恢复数据到指定位置。
mysqlbinlog--stop-position='操作 id' 二进制日志 |mysql-u 用户名 -p 密码
# 从指定的位置开始恢复数据格式
mysqlbinlog--start-position='操作 id' 二进制日志 |mysql-u 用户名 -p 密码

基于时间点的恢复 ```go 跳过某个发生错误的时间点实现数据恢复，有三种方式

1、从日志开头截止到某个时间点的恢复。 mysqlbinlog[—no-defaults]—stop-datetime=’年-月-日小时:分钟:秒’ 二进制日志 |mysql -uusername -ppasswd

2、从某个时间点到日志结尾的恢复 mysqlbinlog[—no-defaults]—start-datetime=’年-月-日小时:分钟:秒’ 二进制日志 |mysql -uusername -ppasswd

3、从某个时间点到某个时间点的恢复 mysqlbinlog[—no-defaults]—start-datetime=’年-月-日小时:分钟:秒’ —stop-datetime=’年-月-日小时:分钟:秒’ 二进制日志 |mysql -uusername -ppasswd ```

mysql 定时备份