系统数据备份及恢复预研文档

系统数据备份及恢复预研文档

1     引言

1.1     背景概述

随着S+平台及其组件项目规模不断扩大，运行时间不断增长，数据库中的数据量也随之增加。在项目运行过程中不可避免遇到数据被破坏的情况，此刻数据备份及恢复方案就尤为重要。S+平台项目中已有的配置导入导出功能使用MySQL dump已经能够实现小数据量情况下的数据备份及恢复功能，但对于稍大数量级的数据无能为力。故对于实际项目状况，应各组件的需求，由S+平台来实现数据库的备份及恢复功能。

1.2     写作目的

本文主要就MySQL数据库备份相关知识的说明，对现存的几种备份及恢复方案简单介绍，并从实际情况来分析各种利弊，对于S+平台的数据库备份及恢复需求选出备选方案。

 

2     术语说明

2.1     数据收集方式分类

2.1.1  完全备份

备份整个数据库，包含用户表、系统表、索引、视图和存储过程等所有数据库对象。但是所花费的时间和空间更多，一般推荐一周或更长的时间周期性做一次完全备份。

2.1.2  增量备份

备份上一次备份（完全备份或上一次增量备份）后，所有发生变化（增加或修改）的文件。即第一次增量备份的对象是进行全备后所产生的增加和修改的文件；第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件，如此类推。

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

2.1.3  差异备份

备份上一次的完全备份后发生变化（增加或修改）的所有文件。差异备份是针对完全备份，虽然其备份文件的大小会随着时间不断增大（在两次完全备份期间），但是数据恢复比较简单，只要先恢复上一次完全备份文件，再恢复最后一次的差异备份即可。

2.2     服务器状态分类

2.2.1  热备份

备份期间数据库的读、写不受影响。

2.2.2  温备份

备份期间数据库仅可以执行读操作。

2.2.3  冷备份

备份期间数据库的读、写操作均中止。

2.3     备份对象分类

2.3.1  物理备份

复制数据库文件，包括数据表结构和表数据等文件。恢复时只有将备份文件复制到指定目录下即可，同时恢复时间较短，但需要考虑数据库版本和操作系统版本的因素。

2.3.2  逻辑备份

将数据导出到文本文件中，所有数据表结构和表数据都以sql形式存储。恢复时执行相应的导出文件中的sql即可，对于大数据量执行时间较长，对于数据库版本和操作系统版本兼容性较高。

3     相关说明

3.1     备份内容说明

数据库备份主要备份内容有：数据文件；日志文件（比如事务日志、二进制日志）；存储过程、存储函数、触发器；配置文件（重要，各个配置文件都要备份）；用于实现数据库备份的脚本、数据库自身清理的Croutab等。

3.2     备份及恢复说明

备份阶段分为热备、温备、冷备，不论物理备份或者逻辑备份。而恢复阶段对于物理恢复则需要关闭数据库服务才能够进行，由于属于物理拷贝，耗时较低；另一方面当需要数据库恢复时，说明数据库中数据已遭到破坏，服务启动状态也无法正常提供服务，故恢复阶段关闭数据库服务完成恢复在启动服务属正常情况。

 

4     数据备份恢复方案

4.1     mysqldump方案

4.1.1  方案概述

mysqldump是一个逻辑备份命令，意思就是将数据库中的数据备份成一个文本文件。

mysqldump命令的工作原理很简单，它先查出需要备份的表的结构，再在文本文件中生成一个CREATE语句，将表中的所有记录转换为一条INSTERT语句。还原数据时就可以使用其中的CREATE语句来创建表，INSERT语句来还原数据。它可以实现整个服务器备份，也可以实现单个或部分数据库、单个或部分表、表中的某些行、存储过程、存储函数、触发器的备份，并且能自动记录备份时刻的二进制日志文件及相应的位置。对于InnoDB存储引擎支持基于单事务模式实现热备，对于MyISAM存储引擎则最多支持温备。

4.1.2  mysqldump完全备份 + 二级制日志增量备份

（1）mysqldump全备

由于Mysql数据库默认的为MyISAM存储引擎所以只有使用温备（备份同时仅支持读请求）进行，所以我们要为所有数据库添加读锁。

[root@stu18 ~]#mysqldump -uroot -pmypass --lock-all-tables--master-data=2 --events --routines--all-databases > /zhao/database_`date+%F`.sql

解析：--lock-all-tables表示为所有表施加读锁；--master-data=2表示在备份文件中记录当前二进制日志的位置；--events表示备份数据的同时备份时间调度器代码；--routines表示备份数据的同时备份存储过程和存储函数；--all-databases表示备份所有库。

[root@stu18 zhao]# less database_2013-08-13.sql

-- Position to start replication or point-in-time recovery from

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=14203;  #这里表示当前处于mysql-bin.000001这个二进制日志中，事件为14203这是通过--master-data=2产生的

-- Current Database: `hellodb`

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `hellodb` /*!40100 DEFAULTCHARACTER SET utf8 */;

（2）二进制全备

方法一：导出二进制日志文件内容

[root@stu18 data]# mysqlbinlog mysql-bin.000001>/zhao/binlog_`date +%F`.sql

方法二：滚动日志复制文件

mysql> flush logs;  #滚动日志

[root@stu18 data]# cp mysql-bin.000001 /zhao/mysql-bin.000001 #复制导出二进制文件

（3）二进制增备

首先添加数据信息

mysql> use hellodb;

mysql> INSERT INTO students(Name,Age,Gender,ClassID,TeacherID)values ('Yang kang',22,'M',3,3);

然后二进制增备

[root@stu18 data]# mysqlbinlog --start-position=14203--stop-position=14527 mysql-bin.000001 > /zhao/binlog_`date +%F_%H`.sql

解析：--start-position=14203是上次全备之后的二进制事件位置；--stop-position=14527最近一天的二进制事件位置。

4.1.3  数据恢复

mysql> DROP DATABASE hellodb;   #删除数据库

############下面这些过程要在离线状态下执行############

mysql> SET sql_log_bin=0;    #先关闭二进制日志

mysql> flush logs;            #滚动日志

[root@stu18 ~]# mysql -uroot -pmypass < /zhao/database_2013-08-13.sql#导入数据库备份文件

[root@stu18 ~]# mysql -uroot -pmypass </zhao/binlog_2013-08-13_19.sql #导入增量备份文件

[root@stu18 ~]# mysql -uroot –pmypass    #登录查看，恢复完成

mysql> SET sql_log_bin=1;

# NOTE：这种备份方式恢复简单，但是恢复还原之后索引会出现错误需要重建，而且备份结果会占据很大的空间，需酌情使用。

4.2     mysqlbackup[z1] 方案mysql_wp_backup.pdf

4.2.1  mysqlbackup概述

mysqlbackup工作原理：mysqlbackup对innodb的表空间进行物理复制，同时记录LSN点，在备份过程中新增加的输入直接写入备份文件的ibbackup_logfile中，同时记录最后的LSN点；mysqlbackup对 myisam进行的是锁表全备，即便增量备份也是完全备份；恢复时，检测对比ibbackup_logfile文件里面与表空间里面的差值，使ibbackup_logfile里面的数据进入事务日志或表空间。

1. 备份

MySQL企业备份工具执行在线热备，无阻塞的MySQL数据库备份。全备份可以在所有InnoDB数据库上执行，而无需中断MySQL查询或更新。此外，支持增量备份，只备份自上次备份后有变化的数据。另外部分备份，支持特定的表或表空间按需要进行备份。

2. 恢复

MySQL企业备份工具能够使用全备份恢复全部数据。一致的时间点恢复（PITR）使数据库管理员能够执行还原到某个特定时间点。使用MySQL备份和binlog，数据库管理员也可以进行细粒度的前滚恢复到一个具体的事务。部分还原允许恢复部分目标表或表空间。此外，数据库管理员可以恢复备份到一个单独的位置，或者快速建立复制配置或管理。

3. 压缩

MySQL企业备份工具支持创建压缩的备份文件，和实际的数据库文件相比，一般备份文件能节省70%到超过90％的存储空间，降低了存储和其他成本。

特点	优点
备份
全量备份	全量备份是针对所有InnoDB数据
增量备份	只备份上一次全量备份后改变的数据
部分备份	备份特定的表和表空间
InnoDB表在线备份	在线进行备份，不妨碍查询或更新
热备和冷备	对MySQL实行在线和离线备份
恢复
完全恢复	可以从一个全量备份的InnoDB数据中完成恢复
基于时间点的即时恢复（PITR）	执行恢复和回滚至某一时间点
回滚恢复	备份可以回滚至具体的事务，以获得更精细的恢复粒度
部分恢复	恢复特定的表或空间
恢复至一个单独的位置	恢复到不同的位置，为快速建立复制配置或管理
高级功能
备份压缩	InnoDB的备份文件可被压缩存储，节省高达90％
无阻挡	InnoDB表的备份完全在线进行，不阻挡任何表的查询或更新
特定的表空间或特定的表	提高了性能，减少备份时间，降低IO的要求
脏数据检测	复制InnoDB数据和日志文件时进行页校验和检查
任务同步	允许其他备份任务实时进行任务同步
只备份实际的数据	不会复制未使用的块。对备份和恢复使用更少的读取和写入，备份文件占用很少空间
便于安装	易于在整个企业中进行安装和部署
高性能
数据库大小无限制	可扩展性，适用于小到大的数据库
运行在MySQL进程空间之外	MySQL进程空间之外运行一个独自的进程，能减少风险和增强性能。MySQL企业级备份不需要安装任何额外的数据库程序，DLLs，脚本，存储过程或在MySQL实例中的表
脚本接口	命令行接口可以轻松地集成到各种调度系统
存储引擎
备份多种存储引擎	InnoDB, MyISAM, Merge, Partition, Archive
备份MyISAM表	MyISAM表复制时，用户可以阅读MyISAM表，但不能修改

 

4.2.2  mysqlbackup完全备份恢复 + 增量备份恢复

A1. 全库备份

命令：

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini --user=root --password=root--databases=test --with-timestamp --backup-dir=C:\MySQL\MySQL_Server_5.5\backupbackup

参数说明：    

--defaults-file  my.ini文件的路径，主要用于一台服务器多个mysql服务

--user      用户名，该用户必须在mysql库里面有创建table、查询、插入的权限。在备份的过程中mysqlbackup会在mysql库下建立backup_history,backup_progress表。用户保留备份的历史信息和备份的基础信息。

--password      密码

--database       需要备份的数据库，要备份多个数据库需要用“”包括起来，每个数据库中间用空格分开。

--with-timestamp用户创建一个备份目录下面当前时间的文件夹，如果没有这个参数,多次备份时，制定同一个目录，会使上一次备份的文件覆盖掉。

--backup-dir   备份目标目录

--backup  标识本次为备份操作

 

A.2全库恢复

第一步：检测事务日志

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini--backup-dir=C:\MySQL\MySQL_Server_5.5\backup\2016-04-26_16-20-39 apply-log

参数说明：

apply-log：因为在备份的时候是在线的，如果有新插入的SQL语句，会记录新增加的LSN点，然后新修改的页面会放到这个文件里面（ibbackup_logfile），同时也会放到表空间里面。当还原使用这个参数的时候，mysqlbackup会检测ibbackup_logfile和表空间的LSN点。然后比较ibbackup_logfile文件表空间LSN的差值，把这个值放到事务日志LOG里面(事务日志如果填满了，会进入表空间的)。

第二步：复制物理文件

mysqlbackup--defaults-file="C:\MySQL\MySQL_Server_5.5\my.ini"--backup-dir="C:\MySQL\MySQL_Server_5.5\backup\2016-04-26_17-59-41"--innodb_log_files_in_group=2 copy-back

# NOTE：在恢复阶段，需要停止数据库服务，my.ini文件中必要要有datadir的参数。

 

B.1 压缩全库备份

命令：

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini --user=root--password="" --compress-level=1 --databases=test4backup--with-timestamp --backup-dir=C:\MySQL\MySQL_Server_5.5\backup backup

参数说明：

--compress-level=1        1为快速压缩，共有9个等级

 

B.2解压全库恢复

第一步：检测事务日志并解压

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini --uncompress--backup-dir=C:\MySQL\MySQL_Server_5.5\backup\2016-04-27_19-22-14 apply-log

参数说明：

uncompress     解压压缩后的文件

第二步：复制物理文件

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini --innodb_log_files_in_group=2--backup-dir=C:\MySQL\MySQL_Server_5.5\backup\2016-04-27_19-22-14 copy-back

# NOTE：在恢复阶段，需要停止数据库服务，my.ini文件中必要要有datadir的参数。增量备份不支持压缩，backup-and-apply-log参数不能跟--compress-level同用。

 

C.1 备份并释放事务日志

备份命令：

mysqlbackup  --defaults-file=/home/mysql-server/mysql3/my.cnf --user=root --password=root  --databases="mysql total2"--with-timestamp    --backup-dir=/home/mysql-server/backup  backup-and-apply-log

参数说明:

backup-and-apply-log    该参数表示在备份的同时完成事务日志的检测功能就，并把ibbackup_logfile与表空间差值的LSN内容放入到了事务日志里面，在恢复时只需备份物理文件即可

恢复命令：

mysqlbackup--defaults-file=/home/mysql-server/mysql2/my.cnf --innodb_log_files_in_group=2--backup-dir=/home/mysql-server/backup/2012-03-21_19-25-09/  copy-back    

 

D.1 增量备份

第一次增量备份：

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini --user=root--password="" --with-timestamp --databases=test4backup --incremental--incremental-backup-dir=C:\MySQL\MySQL_Server_5.5\inbackup--incremental-base=dir:C:\MySQL\MySQL_Server_5.5\backup\2016-04-27_20-00-59backup

参数说明：

--incremental         代表为增量备份

--incremental-backup-dir       增量备份存放到哪个路径下

--incremental-base         增量备份的基础备份或增量备份的文件

第二次增量备份：

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini --user=root--password="" --with-timestamp --databases=test4backup --incremental--incremental-backup-dir=C:\MySQL\MySQL_Server_5.5\inbackup--incremental-base=dir:C:\MySQL\MySQL_Server_5.5\inbackup\2016-04-27_20-02-54backup参数说明：

--incremental-base  相对于本次备份即为上一次增量备份的路径

# 增量备份原理：

增量备份是基于第一次的完全备份之后，通过完全备份最后的LSN点的基础上继续进行备份。当第二次增量备份时，就基于前一次增量备份的LSN点的基础上继续进行备份。所以参数--incremental-base在增量备份的时候，是指向上一次全备份或增量备份的LSN点。

 

D.2 增量恢复

1. 全备检测匹配释放事务日志

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini--backup-dir=C:\MySQL\MySQL_Server_5.5\backup\2016-04-27_20-00-59 apply-log

2. 检测匹配释放第一次的增量备份

mysqlbackup--backup-dir=C:\MySQL\MySQL_Server_5.5\backup\2016-04-27_20-00-59--incremental-backup-dir=C:\MySQL\MySQL_Server_5.5\inbackup\2016-04-27_20-02-54apply-incremental-backup

3. 检测匹配释放第二次的增量备份

mysqlbackup--backup-dir=C:\MySQL\MySQL_Server_5.5\backup\2016-04-27_20-00-59--incremental-backup-dir=C:\MySQL\MySQL_Server_5.5\inbackup\2016-04-27_20-03-57apply-incremental-backup

4. 最后进行物理文件复制

mysqlbackup--defaults-file=C:\MySQL\MySQL_Server_5.5\my.ini--backup-dir=C:\MySQL\MySQL_Server_5.5\backup\2016-04-27_20-00-59 copy-back

# 增量还原原理：

1. 首先检测匹配释放全备事务日志文件(若备份中使用了backup-and-apply-log则不必检测)；

2. 第一次增量备份的文件释放到全备文件里面(首先会进入事务日志,然后是表空间)，所以参数--backup-dir指向全备目录（基于LSN点向后增加）；

3. 第二次增量备份的文件也是释放到全备文件里面(首先会进入事务日志,然后是表空间)，因为第一次的增量备份后，全库里面已经有了第一次的LSN点，故第二次还原的时候同样指向全备文件里面使LSN点在外后增加；

4. 因为增量的文件已经全部进入了事务日志或表空间，此时就可以直接备份物理文件。

 

 

4.3     第三方备份软件（ibbackup或xtrabackup）[z2] 

第三方备份软件都是现存的成熟解决方案，对于各种备份及恢复操作都有很好的支持，但是考虑到使用后会有很强的项目依赖性和未知的不可控性，同时第三方备份软件都主要提供Linux系统下的解决方案，对于Windows系统的支持不尽如人意，故该方案暂不考虑。

4.4[z3] 

4.4     方案分析总结

方案1：mysqldump属于逻辑备份，对于数据量较大的项目的备份及恢复操作耗时都较长，并整个操作在同一个事务中进行容易出错并不易继续进行操作。

方案2：mysqlbackup属于物理备份，是MySQL官方的企业版工具，其性能的优越性及功能的强大是无可比拟的。

方案3：第三方备份软件都是物理备份，其功能和性能都是禁得起市场考验的，但是由于其系统支持缺陷（对于Windows系统支持不好），致使无法采取。

综上所述，方案2是不二之选。

5     系统配置备份恢复方案

5.1     说明

对于系统运行阶段，用户会在S+平台和组件中配置适合自己网络环境中的系统参数。当系统运行异常或其他情况下，用户想一次性恢复到以前的状态，此时该类系统参数的备份数据则尤为重要，所以在数据库数据备份的同时也需要做到系统参数的备份。

5.2     备份恢复说明

现阶段S+平台中已有的配置导入导出功能仅提供了S+平台自己的配置操作，如果需要支持组建的系统数据配置备份及恢复操作，则需要组件向平台注册回调，统一由S+平台来实现配置的备份及恢复操作。现有如下接口：

1.    由组件实现的导出配置信息接口：

public void exportCfg（String moduleName, String desPath）

2.    由组件实现的导入配置信息接口：

public void importCfg（String moduleName, String srcPath）

以上S+平台提供的注册回调接口已经能够满足组件完成配置信息的导入导出操作。

6     备份恢复计划

6.1     备份计划

1．每天的某个固定的时刻(如夜晚01:00:00，时间可自主设定)对数据库进行一次完全备份。

2．每天的某个时段（如0:00:00至23:59:59内）对数据库的事务日志进行差异备份。

3．每天保留最近两天的数据库和事务日志的备份(即：前一天的和前两天的)，自动地删除久于两天前的所有数据库和事务日志的备份。

 

6.[z4] 

 

7     应用场景分析

7.1     备份场景

1.    系统提供web界面的备份配置和操作；

2.    备份按照组件条件进行完全备份；

3.    系统提供数据库备份目标位置可选：远端（可暂时只支持ftp服务器）和本地备份，默认为本地备份；

4.    系统提供数据库备份操作方式可选：定时备份和手动备份，对于定时备份需要设置相应的备份周期组合；

5.    系统提供周期性对数据库进行一次完全备份，以此应对下一个周期内的数据灾难，周期组合可以为每周或者每个周二周四周日的特定时间点；

6.    系统提供周期性对数据库进行一次增量备份，以此应对下一个周期内的数据灾难，该周期可天，在每天的数据量操作较小的时间点进行（数据文件暂不考虑）；

7.    系统在每周日的特定时间点定期删除两周前的所有备份文件，避免备份文件过大；

8.    系统提供数据库备份是对于目标位置的存储空间大小容量的建议，以免备份文件过大导致备份失败；

9.    系统提供数据库备份结果（不论失败或者成功）提示，并将备份相关操作日志写入系统日志中；

10.   显示当前备份状态进度和上次备份信息；

11.   组件数据库中的文件关联关系提供接口让组件实现（组件系统中配置的绝对路径修改配合）；

7.2     恢复场景

1.    系统提供独立于系统的数据库恢复工具（参考iMC），可完成数据库恢复；

2.    暂时只提供本地备份；

3.    数据库恢复工具提供恢复配置文件（可选的恢复时间点和可选的恢复文件位置）；

4.    系统提供建立在数据备份基础上的数据恢复功能，不仅支持同版本数据恢复，也支持特定版本范围内的数据恢复（此处的数据恢复更形象的说应该是数据迁移），对于不同版本间的升级降级情况后期考虑iMC确认；

5.    备份和恢复前后的组件个数不同；

6.    恢复阶段提供异常提示及回调接口（具体到表或者记录）；

7.    对于大版本改动数据结构，是否可以只支持主要基础数据恢复；

---

 [z1]补充下该方案的性能分析

 

详细描述该方案对数据完整性、热备份对数据的影响分析（比如备份时新写入的数据能否备份到？）、备份时对当前运行业务的性

能影响分析

 

系统支持情况、导出的数据是否可以跨系统跨平台？32/64位支持情况？

 

再补充下其他数据文件备份分析，注册回调接口方案

 

 

 [z2]方案1、3也简要说明下是否适用

 [z3]补充个总结，推荐使用方案

 [z4]补充章节，应用场景分析。

 

每个场景一句话就行。能描述清楚该场景即可。