数据库的备份与恢复技术

日志原理目前还没有看到谁说的比较清楚的。

数据库运行过程中，安全事故的发生难以避免。其中有可能是人为因素，也有可能是硬件设备故障，甚至是自然灾难。因此，数据库除了安全性技术防范，还需要有备份与恢复技术来进一步保障数据的安全，当数据被破坏以后，可以尽可能的将数据库调整到破坏前的状态。

数据库备份有多种分类方式。按备份的实现方式，可分为物理备份和逻辑备份，其中物理备份又分为冷备份和热备份；按备份的数据量分，则可分为完全备份、增量备份、差异备份。

一、按备份实现方式划分

1、物理备份
在操作系统里直接备份数据库的数据文件。我有个疑问，直接备份数据库的数据文件，恢复的时候，数据库能识别这些文件吗？能顺利加载它们吗？

1）冷备份
也称为静态备份。先将数据库停止、关闭，然后把数据库的文件全部复制下来，可能就是整个数据库吧，包括数据库本身，以及各种数据文件。通常，我会将数据文件与数据库本身分开存放，复制起来工作量不小。

但是，据说冷备份是数据库备份中最快和最安全的方法。

2）热备份
也称为动态备份。利用备份软件，在数据库正常运行的状态下，将数据库中的数据文件备份出来。直接拷贝是不行的，数据文件处于锁定状态，要利用专用备份软件。

3）冷备份 VS 热备份

简单来说，冷备份快速，但要停止数据库；热备份不用停止数据库，但一旦失败，后果严重，备份不成不说，估计整个数据库都完蛋。

2、逻辑备份
逻辑备份是指利用DBMS自带的工具软件备份和恢复数据库。比如，oracle的export、import（oracle 10g以前是exp、imp）。

逻辑备份可以按表、表空间、用户和全库4个层次备份和恢复数据。但如果数据库非常大，这种备份方式速度很慢，耗时很长，一般采用物理备份。

二、按备份数据量划分

1、完全备份
整个数据库中的数据进行备份。

2、增量备份
备份上一次备份（包括完全备份、增量备份和差异备份）后发生变化的数据。

3、差异备份
备份上一次完全备份后发生变化的所有数据。

三、备份文件的存放

数据备份好了之后并非万事大吉，备份文件不应该只放在服务器本机，还要异机存放、异地存放，避免团灭。

四、日志文件

这里说的日志文件指的是记录事务日志的文件。对于任何一个事务，日志都有非常全面的记录，根据这些记录可以将数据文件恢复成事务前的状态。从事务动作开始，事务日志就处于记录状态，事务执行过程中对数据库的任何操作都记录在内，直到用户提交或回滚后才结束记录。

DBMS的原则是先写日志再修改数据，数据库如果中途挂掉，重启或恢复时，可以根据日志文件结合检查点，按需要重放，以保持数据的一致性。

不同数据库机制不同，按照不同日志文件分类，有的日志文件会循环使用，而有的日志文件则会越来越大。我记得SQL SERVER里，做一次完全备份就可以截断日志文件，将备份前的日志清掉，日志文件得以收缩。oracle好像也有类似机制。而且，日志记录模式，有详细有简洁，作为选项，视乎需要设置。

五、数据恢复

将数据库从错误状态恢复到某一个已知的正确状态的功能，称为数据库的恢复。数据恢复的思想就是冗余，而建立冗余的方法有数据备份和日志文件等。根据故障的不同类型，采用不同的恢复策略：

1、事务故障恢复
事务故障的恢复由系统自动完成，无须DBA参与。具体步骤为：

反向扫描日志文件，对事务的更新操作执行逆操作，直到读取事务开始标记，事务故障恢复完成。（但也有数据库更新数据时，是先更改内存数据，积累到一定量或时间才写入持久化介质，而日志文件是事务提交则写入磁盘，因此事务故障恢复不一定是执行逆操作，也可能是根据日志的记录重放操作？）

这里的事务故障恢复，应该是指不重启数据库的情况。

2、系统故障恢复
系统故障恢复在系统重启时完成，同样不需要用户干预。步骤如下：

1）正向扫描日志文件，找出故障发生前已经提交的事务，记入重做（Redo)队列；同时找出故障发生前尚未完成的事务，记入撤销（Undo)队列。

2）反向扫描日志文件，对撤销队列的事务中的更新操作执行逆操作

3）正向扫描日志文件，对重做队列的事务中的更新操作执行重放操作

3、截止故障与病毒破坏的恢复
步骤如下：

1）载入最后的备份文件，将数据库恢复到最近一次备份时的状态。

2）从故障点开始反向扫描日志文件，找出已提交事务标识，并记入Redo队列

3）从起始点（即最后备份时刻）正向扫描日志文件，将Redo队列的事务重放

4、有检查点的恢复
1）找出检查点建立时所有正在执行的事务

2）未提交的事务做撤销处理

3）已提交的事务重做

检查点类似于一个里程碑。建立检查点的时候，DBMS会将内存中的数据持久化到磁盘里。通常，为提高性能，DBMS都是先修改内存里的数据，积攒到一定量才写入磁盘；而日志倒是事务提交时就马上写入磁盘。建立检查点的好处，就是故障恢复的时候，不用读太多的日志文件，做大量的Redo这种重复操作，只从最后的检查点开始就好。

想想，现在吹得很火的DevOps，其中之一就是持续集成，即我们要经常地、至少每天提交一次代码，否则几天才提交一次，冲突的几率就很大了。数据库检查点也类似，经常性地持久化数据到磁盘。的确是个里程碑。