完全备份、差异备份及增量备份

Posted 2023-05-12

在完全备份，差异备份及增量备份中，差异备份与增量备份的速度哪个更快？为什么？解释下完全备份，差异备份及增量备份，谢谢。

完全备份（Full Backup）

备份全部选中的文件夹，并不依赖文件的存档属性来确定备份哪些文件。在备份过程中，任何现有的标记都被清除，每个文件都被标记为已备份。换言之，清除存档属性。

完全备份就是指对某一个时间点上的所有数据或应用进行的一个完全拷贝。实际应用中就是用一盘磁带对整个系统进行完全备份，包括其中的系统和所有数据。这种备份方式最大的好处就是只要用一盘磁带，就可以恢复丢失的数据。因此大大加快了系统或数据的恢复时间。

❖ 差异备份（Differential Backup）

备份自上一次完全备份之后有变化的数据。差异备份过程中，只备份有标记的那些选中的文件和文件夹。它不清除标记，也即备份后不标记为已备份文件。换言之，不清除存档属性。

差异备份是指在一次全备份后到进行差异备份的这段时间内，对那些增加或者修改文件的备份。在进行恢复时，我们只需对第一次全备份和最后一次差异备份进行恢复。差异备份在避免了另外两种备份策略缺陷的同时，又具备了它们各自的优点。

首先，它具有了增量备份需要时间短、节省磁盘空间的优势；其次，它又具有了全备份恢复所需磁带少、恢复时间短的特点。系统管理员只需要两盘磁带，即全备份磁带与灾难发生前一天的差异备份磁带，就可以将系统恢复。

❖ 增量备份 （Incremental Backup ）

备份自上一次备份（包含完全备份、差异备份、增量备份）之后有变化的数据。增量备份过程中，只备份有标记的选中的文件和文件夹，它清除标记，既：备份后标记文件，换言之，清除存档属性。

增量备份是指在一次全备份或上一次增量备份后，以后每次的备份只需备份与前一次相比增加和者被修改的文件。这就意味着，第一次增量备份的对象是进行全备份后所产生的增加和修改的文件；第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件，如此类推。

这种备份方式最显著的优点就是：没有重复的备份数据，因此备份的数据量不大，备份所需的时间很短。

想了解更多请登录壹进制官网：www.unary.com.cn

参考技术A 1、完全备份（Full Backup）

备份全部选中的文件夹，并不依赖文件的存档属性来确定备份那些文件。在备份过程中，任何现有的标记都被清除，每个文件都被标记为已备份。换言之，清除存档属性。

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

2、差异备份（Differential Backup）

备份自上一次完全备份之后有变化的数据。差异备份过程中，只备份有标记的那些选中的文件和文件夹。它不清除标记，也即备份后不标记为已备份文件。换言之，不清除存档属性。

差异备份是指在一次全备份后到进行差异备份的这段时间内，对那些增加或者修改文件的备份。在进行恢复时，我们只需对第一次全备份和最后一次差异备份进行恢复。差异备份在避免了另外两种备份策略缺陷的同时，又具备了它们各自的优点。首先，它具有了增量备份需要时间短、节省磁盘空间的优势；其次，它又具有了全备份恢复所需磁带少、恢复时间短的特点。系统管理员只需要两盘磁带，即全备份磁带与灾难发生前一天的差异备份磁带，就可以将系统恢复。

3、增量备份 （Incremental Backup ）

备份自上一次备份（包含完全备份、差异备份、增量备份）之后有变化的数据。增量备份过程中，只备份有标记的选中的文件和文件夹，它清除标记，既：备份后标记文件，换言之，清除存档属性。

增量备份是指在一次全备份或上一次增量备份后，以后每次的备份只需备份与前一次相比增加和者被修改的文件。这就意味着，第一次增量备份的对象是进行全备后所产生的增加和修改的文件；第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件，如此类推。这种备份方式最显著的优点就是：没有重复的备份数据，因此备份的数据量不大，备份所需的时间很短。但增量备份的数据恢复是比较麻烦的。您必须具有上一次全备份和所有增量备份磁带（一旦丢失或损坏其中的一盘磁带，就会造成恢复的失败），并且它们必须沿着从全备份到依次增量备份的时间顺序逐个反推恢复，因此这就极大地延长了恢复时间。本回答被提问者采纳 参考技术B 1.按备份数据量，从多到少排序
完全，差异，增量

2.按数据恢复速度，从快到慢排序
完全，差异，增量。
完全备份

备份全部选中的文件夹，并不依赖文件的存档属性来确定备份那些文件。 　　（ 在备份过程中，任何现有的标记都被清除，每个文件都被标记为已备份，换言之，清除存档属性）。 　　完全备份就是用一盘磁带对整个系统进行完全备份，包括系统和数据。这种备份方式的好处就是很直观，容易被人理解。而且当发生数据丢失的灾难时，只要用一盘磁带（即灾难发生之前一天的备份磁带），就可以恢复丢失的数据。然而它也有不足之处：首先由于每天都对系统进行完全备份,因此在备份数据中有大量是 重复的，例如操作系统与应用程序。这些重复的数据占用了大量的磁带空间，这对用户来说就意味着增加成本；其次，由于需要备份的数据量相当大，因此备份所需 时间较长。对于那些业务繁忙，备份窗口时间有限的单位来说，选择这种备份策略无疑是不明智的。
差异备份　　
复制自上一次普通备份或增量备份以来被创建或更改的文件的备份。它不将文件标记为已经备份（换句话说，没有清除存档属性）。如果您要执行普通备份和差异备份的组合，则还原文件和文件夹将需要上次已执行过普通备份和差异备份

增量备份　　
增量备份是针对于上一次备份（无论是哪种备份）：备份上一次备份后，所有发生变化的文件。 　　（增量备份过程中，只备份有标记的选中的文件和文件夹，它清除标记，既：备份后标记文件，换言之，清除存档属性。）说白了就是：只备份当天有变化的数据，并且是带标记的数据，当备份完后还要清除标记，总之他占用空间小，恢复起来麻烦。

不同备份类型可以存在一定组合，下面的示例供您参考： 　　完全备份和差异备份 　　在星期一进行完全备份，在星期二至星期五进行差异备份。如果在星期五数据被破坏了，则你只需要还原星期一完全的备份和星期四的差异备份。这种策略备份数据需要较多的时间，但还原数据使用较少的时间。 　　完全备份和增量备份 　　在星期一进行完全备份，在星期二至星期五进行增量备份。如果在星期五数据被破坏了，则你需要还原星期一正常的备份和从星期二至星期五的所有增量备份。这种策略备份数据需要较少的时间，但还原数据使用较多的时间。 参考技术C 差异备份是针对完全备份：备份上一次的完全备份后发生变化的所有文件。 （完全备份和增量备份 在星期一进行完全备份，在星期二至星期五进行增量备份。 参考技术D 增量备份

mysql备份（增量备份）

数据库的备份方式：

• 完全备份  full backup，备份全部字符集。
• 增量备份 incremental backup 上次完全备份或增量备份以来改变了的数据，不能单独使用，要借助完全备份，备份的频率取决于数据的更新频率。
• 差异备份 differential backup 上次完全备份以来改变了的数据。

　　建议的恢复策略：
　　完全+增量+二进制日志
　　完全+差异+二进制日志

我们常用的备份方式：

备份整个数据库

$> mysqldump -u root -h host -p dbname > backdb.sql

 

备份数据库中的某个表

$> mysqldump -u root -h host -p dbname tbname1, tbname2 > backdb.sql

 

备份多个数据库

$> mysqldump -u root -h host -p --databases dbname1, dbname2 > backdb.sql

 

备份系统中所有数据库

$> mysqldump -u root -h host -p --all-databases > backdb.sql

 

1. 完全+增量+二进制日志

　　在备份前需要献给表加锁

　　--lock-all-tables 是对要备份的数据库的所有表施加读锁

　　--lock-table 仅对单张表施加读锁，即使是备份整个数据库，它也是在我们备份某张表的时候才对该表施加读锁，因此适用于备份单张表

　　首先需要做完全备份：

# sudo mysqldump -uroot --single-transaction --master-data=2 --databases test > /backup/testdb_`date +%F`.sql  # 生成了一个"testdb_2019-11-13.sql"的完全备份文件

  

--single-transaction: 基于此选项能实现热备InnoDB表；因此，不需要同时使用--lock-all-tables；
--master-data=2  记录备份那一时刻的二进制日志的位置，并且注释掉，1是不注释的
--databases hellodb 指定备份的数据库

 

　　然后修改数据库表，找到修改后的日志位置：

mysql> insert into people (user_name,age) values(\'mm\',18);

# cat /backup/testdb_2019-11-13.sql | less
找到备份起始位置：
-- CHANGE MASTER TO MASTER_LOG_FILE=\'mysql-bin.000002\', MASTER_LOG_POS=960;     # 960 是完全备份日志中的结束位置
查看当前日志位置：
mysql>  show master status;

　+------------------+----------+--------------+------------------+-------------------+
　| File 　　　　　　  | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
　+------------------+----------+--------------+------------------+-------------------+
　| mysql-bin.000002 | 1228 　　| 　　 　　　　　 | 　　 　　　　　　　 | 　　 　　　　　　　　|　　# 1228 是插入一条数据后二进制日志当前位置
　+------------------+----------+--------------+------------------+-------------------+

 

　　开始生成增量备份：

# sudo mysqlbinlog --start-position 960 --stop-position 1228 /var/log/mysql/mysql-bin.000002 > /backup/testdb_`date +%F_%H`.sql
# ll /backup  # 可以看到有一个"testdb_2019-11-13_12.sql"的备份文件

   

再一次插入数据到数据库中
mysql> insert into people (user_name,age) values(\'gg\',18);   关闭二进制日志
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File 　　　　　　  | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 | 1496 　　| 　　 　　　　　 | 　　 　　　　　　　 | 　　 　　　　　　　　|　　# 1496 是插入第二条数据后的二进制日志位置
+------------------+----------+--------------+------------------+-------------------+
# mysqlbinlog --start-position 1228 --stop-position 1496 /var/log/mysql/mysql-bin.000002 > /backup/testdb_`date +%F_%H`.sql
# ll /backup # 又多了一个"testdb_2019-11-13_13.sql"文件

  

  可以看到有三个文件，第一个是我们的完全备份文件，第2、3个就是增量备份文件

先让mysql离线：
mysql> set sql_log_bin=0;   关闭二进制日志
mysql> flush logs; 　　　　  滚动下日志　

 

 　　模拟数据库损坏：

mysql> drop  database test;　　# 删除test数据库

 

 　　开始恢复数据：

# mysql -uroot -p </backup/testdb_2019-11-13.sql　　　　# 导入完全备份文件
# mysql -uroot -p </backup/testdb_2019-11-13_12.sql　　# 导入第一次增量备份
# mysql -uroot -p </backup/testdb_2019-11-13_13.sql　　# 导入第二次增量备份

查看是数据是否恢复：
mysql> select * from test.people;

  

  此时的数据库已经完全恢复了，我们新插入的数据也在数据库里。

mysql> set sql_log_bin=1;  # 确认没问题后开启bin日志