sql server 备份与回复种类生机勃勃 必备知识

一.概述

  前面介绍了简单恢复模式和大容量恢复模式,这篇继续写完整恢复模式下的备份与还原。在完整恢复模式里最大的优点是只要能成功备份尾日志,就可以还原到日志备份内包含的任何时点(“时点恢复”)。当然对比前二种模式它是牺牲了磁盘I/O性能。

恢复模式

备份策略

数据安全性

I/O性能

简单恢复

完整备份+差异备份

安全最差。最后一次备份之后,所有数据操作丢失。

最优

大容量恢复

完整备份+差异备份+日志备份

折中。批量操作有丢失风险。尾日志备份失败。最后一次备份之后,所有数据操作丢失

折中

完整恢复

完整备份+差异备份+日志备份

相比上面二种最安全。尾日志备份失败。最后一次备份之后,所有数据操作丢失

最差

  在完整恢复模式下,最常见的备份策略,如下图所示:图片 1

一.备份概述

  数据安全是数据库的生命,数据库在使用过程中难免会遇到如:使用者的误操作或是被恶意修改,硬件故障导致数据文件无法被访问,自然灾害导致机房在物理上的损毁。本章从备份与恢复的功能作为解决问题的切入点。在实际工作中会遇到:使用什么样的备份策略(比如完整备份,文件备份,差异备份,日志备份),如何减少备份恢复时间(比如尽快恢复上线),如何将数据库恢复到想要的时间点(比如恢复到误操作以前),如何迁移数据库系统到一台新机器(比如用户账号,密码,任务脚本备份还原)。

  1.备份类型

     在sql
server数据库里包括数据文件和日志文件,相应包括数据备份和日志备份。数据备份可以是完整数据库备份,文件备份,差异备份也叫增量备份。日志备份也叫事务日志备份。

完整备份

   会记录数据库里的所有信息,可以将数据库数据恢复到某个时间点的状态。但一个大的数据库备份可能

需要很长时间。假如每天或每小时只用完整备份类型就需要发费大量存储空间和备份恢复时间,仅完整备份不能满足用户需求。

文件备份

   备份一个或多个文件或文件组的所有数据,多数针对大型数据库。文件备份+日志备份=完整备份。如果是一个文件损坏,只需还原该文件,从而加快恢复速度。

差异备份                              要求数据库之前做过一次完整备份称为基准。它是完整备份以后,发生更改的数据. 便于频繁备份,降低数据丢失的风险。
日志备份   要求数据库之前做过一次完整备份,自从上次完整备份或日志备份以后写入的日志记录。连续不断的日志链可以将数据库还原到任意时间点。 所以在备份策略中扮演重要角色。

   2.  备份策略

    (1)数据库最多能容忍多长时间的数据丢失。
    (2)投入多少人力物力做数据库备份和恢复策略。每次备份都会有时间间隔,数据丢失容易发生在最近一次备份之后的所有数据库操作,之后如文件损坏数据库需要恢复,备份尾日志肯定不成功,数据也会丢失,
为了保证数据不丢失需要引用镜像等技术。
    (3)
备份文件越多,数据库恢复的文件也越多,要建立一个合适的备份管理制度。备份虽然不会阻塞数据库的正常操作,但会产生一系列的磁盘读写,这时要避免在服务器I/O繁忙时。备份越多,失败的概述也会越大,需要管理员及时处理错误,将备份任务恢复常态。

  3. 常用的备份方法

分级

数据备份

日志备份

数据库级

完整数据库备份

差异数据库备份

日志备份

文件级

完整文件备份

差异文件备份

 

二. 备份

  在前章中讲到了大容量恢复模式下的备份。备份策略与大容量模式是一样的,同样是完整备份+差异备份+日志备份。这里要突出点是:当误操作发生后,如何还原到误操作之前的一分钟,找出误操作之前的数据。
在”sql server
日志文件结构及误操作数据找回”中有介绍误操作数据找回,但是基于第三方工具ApexSQL
Log。虽然该工具方便,但要收费哟。

  我这里有一个BackupTest库,库里有个Employees表

use master
--设置完全模式
ALTER DATABASE BackupTest SET  RECOVERY FULL  
--创建备份设备(有就不要执行)
use master
exec sp_addumpdevice 'disk', 'BackupTestDevice','F:\SqlService\backup\BackupTestBackup.bak'
go
--做一次完整备份到备份设备中(备份基准)
backup database  BackupTest to BackupTestDevice

--新增数据
insert BackupTest.dbo.Employees values('湖南长沙')
insert BackupTest.dbo.Employees values('湖南湘潭')
--日志备份
backup log BackupTest to BackupTestDevice

 备份集如下所示:

图片 2

-- 误操作发生, 忘记加where条件,操作时间是:2018-8-12 10:55  
delete from BackupTest.dbo.Employees 

二. 数据库恢复模式下的备份类型

    上面说了备份涉及的几种类型,这里就得说数据库恢复模式对备份类型的支持及特点。sql
server有三种数据库恢复模式设置包括:简单恢复模式,完整恢复模式,大容量恢复模式。

图片 3

  2.1  简单恢复模式
    在简单恢复模式下,不能做日志备份,只支持最简单的备份和还原方式,容易管理,数据库最后一次备份之后做的数据修改将全部丢失。为了降低风险,可以引入差异备份。差异备份的开销一般都比完整备份低,可以经常运行。如果数据库比较庞大或者不允许长时间的数据丢失,那这种简单恢复模式就不适合。在总结下:

    优点:

    (1)日志文件占用物理空间少日志增长慢。

    (2)对SQL执行性能优,能最小化日志。

    缺点:

    (1)不支持日志备份.

    (2)无法实现零丢失,恢复时间点至上一次备份时。

    (3)切换到其它恢复模式时,日志链中断。

  2.2 大容量恢复模式

    又叫大批量恢复模式,可以使用日志备份,它能够对某些大批量操作提供最佳的性能和最小的日志使用空间,这些大批量包括bulk
insert, bcp,create index, select into, writetext ,
updatetext。也就是说这些操作有数据丢失风险,相对完全恢复模式,这些操作都是完全记录的。总结下:

     优点:

         (1)日志文件占用物理空间少(日志增长慢)。

         (2)对SQL执行性能优(最小化日志)。

         (3)支持切换到完整模式不中断日志链。

    缺点:

         (1)还原大批量操作,数据有丢失风险如bulk insert, select
into等。

  2.3 完整恢复模式

    也可以叫完全恢复模式,在此模式下,所有操作都会被完整记录下来,如insert每新增的一行,delete每删除的一行,还包括大批理操作如bulk
insert等,都会记录到事务日志中。 包括create
index操作也会被完全记录,在日志恢复时不必要重建索引,恢复会很快。使用日志备份,可以定义一种很频繁的频率,5份钟甚至更短时间来做备份,以防止出现故障数据丢失。但是备份数量越多,恢复时需要严格按备份产生的顺序依次恢复,中间不能有任何备份缺失。

    优点:

    (1)
使用了日志备份可以实现零丢失(如果能进行尾日志备份,能还原到任意时间点)。

    (2)支持切换到大容量模式不中断日志链。

    缺点:

    (1)日志文件空间占用大必须定期日志备份,达到日志空间重用。

三.还原(1)

  当误操作发生后,是需要找管理员来进行数据还原。
如果数据库太大,还原是需要很长时间(注意使用副本,不要使用生产库)。
这种情况下就需要等待了。 避免的方法:(1)是做sql审核,不在Managemnet
studio里直接操作,避免此类事情发生.(2)是使用粒度更小的备份方式,但相应的复杂些。

--步骤1 备份尾日志
use master
go
backup log BackupTest to BackupTestDevice with norecovery 

图片 4

go
--步骤2 从备份恢复一个全备份 ,norecovery(正在还原...)不可读写. file指备份集位置号
restore database BackupTest from BackupTestDevice with file=19, norecovery --事务不恢复

--步骤3 
restore log BackupTest from BackupTestDevice  with file=20,  norecovery --事务不恢复

--步骤4 用stopat恢复到10:54
restore log BackupTest from BackupTestDevice  with file=21, stopat='2018/8/12 10:54', recovery --事务恢复

--数据又回来了
select * from  BackupTest.dbo.Employees 

  图片 5

四.还原(2)

  在前面介绍中,有讲过,完整恢复模式切换到大容量模式,日志链是不会中断。下面来验证

--从完整恢复模式切换到大容量模式
ALTER DATABASE BackupTest SET  RECOVERY bulk_logged 
-- 新增
insert BackupTest.dbo.Employees values('湖南株洲')
--日志备份
backup log BackupTest to BackupTestDevice
-- 删除
delete from BackupTest.dbo.Employees 

-- 尾日志
backup log BackupTest to BackupTestDevice with norecovery 

 备份集如下所示,日志文件ID:22是在大容量模式下备份的,23是尾日志

图片 6

restore database BackupTest from BackupTestDevice with file=19, norecovery --事务不恢复
restore log BackupTest from BackupTestDevice  with file=20,  norecovery --事务不恢复
restore log BackupTest from BackupTestDevice  with file=21,  norecovery --事务不恢复
restore log BackupTest from BackupTestDevice  with file=22,  recovery 

  当日志还原到文件ID:22时,报错,如下图所示

图片 7

   跳过文件ID:22, 使用23来提交事务,也会报错,如下所示:

restore log BackupTest from BackupTestDevice  with file=23,  recovery

图片 8

   经过测试,还原失败,错误是指:与上一次还原到指定时间点有关系。

  下面在测试一个新库TestFULLToBulk

--设置完全模式
ALTER DATABASE TestFULLToBulk SET  RECOVERY FULL  
--做一次完整备份到备份设备中(备份基准)
backup database  TestFULLToBulk to BackupTestDevice
insert TestFULLToBulk.dbo.product values('湖南株洲')
--日志备份
backup log TestFULLToBulk to BackupTestDevice
--设置大容量
ALTER DATABASE TestFULLToBulk SET RECOVERY bulk_logged   

insert TestFULLToBulk.dbo.product values('湖南湘潭')
--日志备份
backup log TestFULLToBulk to BackupTestDevice

  备份集如下:文件ID28是在大容量下进行的备份

  图片 9

backup log TestFULLToBulk to BackupTestDevice with norecovery 
go
restore database TestFULLToBulk from BackupTestDevice with file=26, norecovery 
go
restore log TestFULLToBulk from BackupTestDevice  with file=27,  norecovery 
go
restore log TestFULLToBulk from BackupTestDevice  with file=28,  recovery 

  上面还原成功,证明了完整恢复模式切换到大容量模式,日志链是不会中断。

 

相关文章