增量备份与完全备份的区别？

Posted 2023-05-12

完整备份是指备份你所指定的所有文件，不管它以前有没有备份过。
增量备份是指只备份新增加的文件或者内容发生变化的文件。
一般这两个备份方式都是搭配使用的。我们用一个星期来举个例子。比如，你现在要备份一个文件夹“资料”，里面有10个文件。星期一你做完整备份，此时备份的是10个文件，星期二，里面又添加了一个新的资料文件，此时你做增量备份，那么星期二的增量备份实际上只备份了这个新增的文件，是一个文件；星期三，你对这个文件夹里的一个文件内容做了修改，再做增量备份，那么星期三的增量备份实际上只备份了这个被修改的文件，还是一个，以此类推。（当然，如果是添加两个文件那就是只备份两个，修改两个就是两个）。结果到星期六了，不小心把这个资料文件夹删除了，那么如果要恢复星期五的数据，那就是先恢复星期一的完整备份，因为这个完整备份里只有10个文件，所以再逐个恢复星期二到星期五的增量备份，因为这些增量备份中只有当天的新文件或者是内容发生变化的文件。每一个增量备份是不包括前一天增量备份的内容的。 参考技术A 全量备份是指对某一时间点上的所有数据进行全量备份，包括系统和所有数据。这种备份方式每次都需要对系统和所有数据进行一次全量备份。如上，如果两次备份之间数据没有任何变化，那么两次备份的数据是一样的。也就是说100GB的数据即使没有发生任何数据变化，也会多耗费100GB的存储空间去做备份。但这种备份方式最大的好处就是在恢复丢失数据时，只需要对一个完整的备份进行操作就能够恢复丢失数据，大大加快了系统或数据恢复的时间。
增量备份即在第一次全量备份的基础上，分别记录每次的变化。由于增量备份在备份前会判断数据是否发生变化，并仅记录每次变化情况，所以相较于其他两种备份方式它最大的好处在于其所需存储空间最少的（相同的变化情况下），备份速度最快的。当然在数据还原上来说，它的恢复时间是最长的，效率较低。恢复数据时，需要在第一次完备的基础上，整合每次的一个变化情况。
差异备份就是在第一次全量备份的基础上，记录最新数据较第一次全量备份的差异。简单来说，差异备份就是一个积累变化的过程：在全量备份之后，第一天记录第一天的变化，第二天记录第一天和第二天的变化，以此类推......因此，恢复系统或者数据时，只需要先恢复全量备份，然后恢复最后一次的差异备份即可完成。所以差异备份占用的储存空间和所需恢复时间介于全量备份和增量备份之间。 参考技术B 增量备份前会比较文件，如果有变动才备份覆盖前一次的备份，完全备份是把所有文件覆盖前一次的备份。

MySQL增量备份与恢复

上篇讲的完全备份我们现在总结出完全备份会有大量的重复数据，并且完全备份的时间与恢复的时间很长。解决完全备份存在的问题就是使用增量备份的方式，增量备份就是备份自上一次备份之后增加或改变的文件或者内容。

增量备份的特点：

优点：没有重复数据，备份量不大，时间短。
缺点：需要上次完全备份及完全备份之后所有的增量备份才能恢复，
MySQL没有提供直接的增量备份方法，但是可以通过mysql的二进制文件（binarylogs）间接实现增量备份。二进制日志对备份的意义如下：
（1）二进制日志文件保存了所有更新或者可能更新数据库的操作。
（2）二进制日志在启动MySQL服务器后开始记录，并在文件达到max_binlog_size所设置的大小或者接收到flush logs命令后重新创建新的日志文件。
（3）只需要定时执行flush logs方法重新创建新的日志，生成二进制文件序列，并及时把这些日志保存到安全的地方就完成了一个时间段的增量备份。

增量备份与恢复实验：

（1）先进MySQL的配置文件，配置二进制日志，重启服务：
[[email protected] ~]# vim /etc/my.cnf

[[email protected] ~]# systemctl restart mysqld.service //配置完重启服务

（2）接下来登录MySQL数据库，创建数据库并建表写入内容：


（3）数据库、表创建好之后做一个完全备份：
[[email protected] ~]# mysqldump -uroot -p company > /opt/company$(date +%F).sql

（4）创建数据库 表的所有数据和操作将完整记录在第一个二进制文件（mysql-bin.000001）中：
[[email protected] data]# mysqlbinlog --no-defaults mysql_bin.000001

（5）使用flush logs命令生成一个二进制文件：
[[email protected] data]# mysqladmin -uroot -p flush-logs

（6）接下来修改表内容，会在第二个二进制文件mysql_bin.000002中记录增量数据及操作：

（7）查看新生成的二进制日志文件 [[email protected] data]# mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql_bin.000002

（8）接下来将增量备份的文件恢复到数据库company中的表中：
[[email protected] data]# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -uroot -p
[[email protected] data]# mysqlbinlog --no-defaults mysql-bin.000002 | mysql -uroot -p //使用二进制文件进行恢复操作（需要注意：恢复的顺序，要先恢复最先生成的二进制文件，然后依次执行）

---

(9) 接下来是基于时间点恢复：
通过查看二进制日志文件： 180903 15:31:56 错误操作时间点 --stop-datetime
[[email protected] data]# mysqlbinlog --no-defaults --stop-datetime=‘2018-09-03 15:31:56‘ /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p
通过查看二进制日志文件：180903 15:32:10 下一个正确操作的时间点 --start-datetime
[[email protected] data]# mysqlbinlog --no-defaults --start-datetime=‘2018-09-03 15:32:10‘ /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p

---

(10) 接下来是基于位置点恢复：
通过查看二进制日志文件： At 833 上一次可以被正确执行的位置 --stop--position
[[email protected] data]# mysqlbinlog --no-defaults --stop-position=‘833‘ /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p
通过查看二进制日志文件：At 930 下一次可以被正确执行的位置 --start--position

[[email protected] data]# mysqlbinlog --no-defaults --start-position=‘930‘ /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p

---

本篇总结：

MySQL没有直接提供增量备份的工具，需要借助二进制日志文件进行操作。

使用分割日志的方式进行增量备份。
增量恢复需要根据日志文件的时间先后，逐个执行。
使用基于时间和位置的方式进行恢复，可以更精确地恢复数据。
大企业应每周做一次全备，每天做一次增量备份；中小企业应每天进行一次全备。