如何制定完美的SQL Server备份策略

日期: 2013-03-18 作者:张亮亮 来源:TechTarget中国

作为一个DBA,最重要任务之一可能就是恢复一个应用数据库。当数据库由于某种原因遭到损坏时,就需要将数据恢复到最近一次的正常状态。为了做到这一点,DBA需要制定一个备份策略,使之支持各种不同的恢复情况。因此,制定一个保证顺利恢复数据的备份流程应该是DBA的最高优先级任务。如果没有相应的规划,数据库恢复过程就无法成功完成,DBA也可能因此丢掉工作。在本文中,我将介绍一些关于开发、创建和测试备份策略的概念。

  理解备份需求

  没有人知道数据库将发生什么情况。它可能由于代码错误或硬件错误而遭到破坏,也可能由于数据中心火灾、水灾或其他灾难事件而丢失数据。为了恢复数据或减少数据库损失,必须根据特定要求备份数据库。

  在创建备份策略之前,需要确定备份需求。所谓备份需求,是指需要确定允许丢失多少数据,以及需要多长时间才能恢复所丢失或损坏的数据。允许丢失多少数据,这通常称为恢复点目标(Recovery Point Objective, RPO),而用于恢复丢失数据的时间长度通常称为恢复时间目标(Recovery Time Objective, RTO)。

  为了确定环境的RPO或RTO,必须与数据拥有者或客户面谈。客户可以确定他们的数据重要性,以及是否能够在数据库损坏或数据丢失之后重新创建或重新输入数据。下面是一些确定需求的问题列表:

  • 数据发生变化的频率有多快?
  • 当数据损坏或丢失时,是否能够重新输入或重新创建数据?
  • 如果能够重新输入或重新创建数据,时间控制在什么范围才合理?
  • 当执行恢复操作时,能够容忍的系统停机时间有多长?
  • 能够容忍的数据丢失有多少?

  客户需求将指导DBA确定需要设计、创建和测试哪一种备份和恢复策略。

  远程、本地和第二备份位置

  备份需求很重要,但还需要考虑保存数据库备份的位置。需要保证备份文件的可靠保存,以备在需要时使用,同时要保证它们不会受到服务器故障或数据中心整体事故的影响。因此,DBA需要考虑备份文件的本地存储位置,也可以考虑将备份文件存储在远程位置。

  如果要存储在本地,则需要写入或存储备份文件,使得在发生数据库服务器故障或数据库损坏时能够随时使用。将备份文件直接保存在数据库服务器上,可以实现较快的备份写入速度,因为这个过程没有网络I/O操作。但是,如果将备份保存在数据库服务器上,那么当服务器出现故障时,就可能会丢失备份文件。另一种方法是将备份保存到网络磁盘上。这个就可以将备份文件与数据库服务器分离,但是这种方法并没有应对网络备份主机出现问题的第二位置。最好要将备份文件复制到其他备份位置,如磁带机或网络备份存储解决方案。采用这种方式之后,当主备份设备出现故障时,就仍然能够从第二个位置取回备份文件。DBA要保证在备份文件创建之后,马上将它们复制到第二个位置。这样可以最大程度缩短只有一个备份副本的时间。

  在本地保存备份文件,就可以在需要恢复数据时快速获得备份文件。但是,当本地设施出现重大事故时,如火灾、水灾或其他自然灾害,又会发生什么结果?如果本地备份发生了问题,那么除非预先将备份文件复制到远程位置,否则就无法恢复数据。由于是开发备份解决方案,所以必须制定一个计划,将备份文件复制到一个安全的远程存储位置。

  备份副本保存多长时间?

  当确定特定数据库的备份需求时,还需要确定保存这些备份文件的时间长度。保存备份文件的时间越长,就需要为这些备份文件准备更大的磁盘空间。在确定备份文件保存时间时,并没有固定的答案或时间规定。首先需要评估具体环境,然后再确定需要多少个副本,以及这些副本的保存时间。在确定需要保存多少副本时,应该考虑以下问题:

  • 数据库更新频率是多少?
  • 发现数据问题需要多长时间?
  • 恢复备份文件要多快才合理?

  当确定保存的备份数量时,需要平衡恢复速度与所使用的空间大小。一旦确定了备份保存时间及所需要的副本数量,一定要让数据拥有者明确计划保存的副本数量及它们恢复回数据库的速度。一定避免这种情况:数据拥有者要求将数据库恢复到30天以前,而你只保存了14天的备份。

  备份类型

  数据库备份类型有很多种。下表列出了不同的备份类型及其用法的简单描述:

备份类型

描述

纯复制(COPY_ONLY)

不影响正常备份顺序的FULL或TRANSACTION备份

完全(FULL)

备份数据库的所有数据

增量(DIFFERENTIAL)

备份从上一次FULL、PARTIAL或FILE备份之后发生变化的所有数据

事务日志(TRANSACTION LOG)

备份事务日志信息(仅仅与处于FULL恢复模式的数据库相关)

文件(FILE)

备份一个或多个数据库文件或文件组

部分(PARTIAL)

备份所有读写文件组,选择性备份一个或多个只读文件

  这里每一种类型都有细微区别,它们有不同的用途。最常用的三种备份类型是:完全备份(FULL)、增量备份(DIFFERENTIAL)和事务日志备份(TRANSACTION LOG)。

  要确定哪一种备份类型组合最适合你的环境。下面是一些指导方法:

  • 如果不担心数据库备份时间写入恢复数据,那么可以执行FULL数据库备份。如果这种类型符合要求,那么还应该将数据库设置为SIMPLE恢复模式,以控制事务日志的增长速度。
  • 如果数据库很大,需要较长时间才能完成备份,备份文件又非常大,或者数据库中并非有很多数据库会发生变化,那么可能更适合组合使用FULL或连续DIFFERENTIAL备份方式。
  • 如果数据经常变化,而且希望能够及时恢复,那么要考虑组合使用FULL和TRANSACTION LOG备份,或者根据数据库大小使用DIFFERENTIAL备份。
  • 如果知道只有特定的文件或文件组发生更新,则适合使用FILE和PARTIAL备份方式。
  • 如果想要采用特殊备份方法,例如将数据库移到测试服务器进行测试,但是又不想破坏正常的生产备份过程,那么可以考虑使用COPY_ONLY备份方法。

  当数据库环境中实现特定的数据库备份策略时,一定要完全理解RTO和RPO需求,以及每一种不同的备份类型与存储位置如何帮助您实现RTO和RPO时间要求。

  建立备份解决方案

  一旦确定了备份需求,以及用于保存备份的本地与远程位置,就可以考虑如何执行备份了。大部分人都会使用三种方法创建数据库备份:购买客户自定制(COTS)解决方案,使用SQL Server内置的维护计划方法,或者自行创建备份解决方案。每一种方法都有其自身的优点。

  COTS解决方案一般会包含许多附加条件,而且有时候会有比维护计划或自行开发解决方案更多的特性。维护计划解决方案非常容易实现,并且有足够的功能为大多数组织实现可靠的备份解决方案。如果有一些特殊的备份需求,那么实现需求的唯一方法就是自行开发一个备份方案。在自行开发时,要考虑一个问题:DBA需要不停地维护这个解决方案,而COTS和维护计划解决方案则由供应商负责维护。

  确认可以执行恢复操作

  原因很简单,即使备份了数据库,也不意味着就能够从备份恢复数据库。在创建备份之后,还应该确认这些备份是有效的。

  有几种方法可以确认备份有效,其中一种是适时地从保存的备份执行一次真正的数据库恢复操作。这种方法可能不适用于生产环境,但是至少应该定期进行测试,保证可以在非生产环境恢复所保存的备份。

  有时候可以验证备份是否写入正确。这可以通过“BACKUP VERIFYONLY”命令实现。这个命令实际上会读取备份文件,然后验证备份的数据是否能够真正恢复。通过使用SQL Server的验证方法,能够检查备份是否写入正确。

  恢复一个数据库备份仅仅意味着该备份是正确的,但是并不意味着所有备份是正确的。DBA应该考虑定期执行裸机恢复。要尝试这种方法,需要找一台未使用的主机,然后依次恢复操作系统、SQL Server软件和所有的数据库(包括系统数据库)。执行一次服务器完全恢复可以确认备份策略的有效性,并且也能够有效保证在真正发生灾难事故时能够执行完全恢复。

  保证备份文件的安全

  在创建备份计划时,需要考虑备份文件的保存位置,以及这些位置的安全性。由于备份文件包含了企业数据,所以需要保证这些备份位置是足够安全的。保证备份位置的安全性,才能保证备份文件不会意外落入外人手中。

  如果数据库包含敏感数据,如信用卡号或个人身份数据,那么需要注意这些数据库备份文件的访问权限。如果数据库备份文件没有加密,并且他们有SysAdmin权限,那么其他人很容易通过恢复数据库备份而获取数据。

  如果有保密要求,或者数据库存储了敏感数据,那么应该保证只有授权查看、管理和使用数据库备份的人员才允许访问备份位置。此外,可以要求应用程序在数据库中加密保存数据,或者采用某种方式加密数据库备份文件。加密备份文件的一种方法是在包含未加密保密数据的数据库中打开透明数据库加密(Transparent Database Encryption, TDE)。如果使用TDE加密备份文件,就需要开发一种方法,管理和恢复用于加密数据库的证书。如果不能恢复证书,就无法恢复TDE加密数据库。

  规模安全性

  在开发备份解决方案时,首先需要确定备份的RPO和RTO。确定了这些时间线,就可以指导选择符合要求的备份类型,以及恢复备份的位置。

  规模安全性是开发备份策略时需要考虑的问题。正如动物世界一样,只有大量同种动物聚集时,一些特定物种才会感到安全。如果备份数量多于需求,那么DBA也会有安全感。

  只有可以恢复所创建的数据库备份时,备份解决方案才会最终生效。DBA需要定期验证备份,而且应该考虑至少每一年左右执行一次全面服务器恢复测试。

      本文首先发布在《数据库工程师》电子杂志,更多精彩内容,请下载《数据库工程师》2013年1月刊完整版PDF。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者

张亮亮
张亮亮

TechTarget特邀编辑。毕业于北京邮电大学网络技术研究院。熟悉软件开发测试的各个环节和流程,对操作系统,数据库,计算机网络等有较为深入的理解。现就职于中国电子科技集团公司下属研究所,从事软件研发工作。热衷于英文的学习交流,平时喜欢户外运动,音乐,电影。

相关推荐

  • Notre Dame对云端SQL Server性能基准的探索实践

    确立SQL Server的性能基准,对于云端迁移来说是至关重要的第一步,一位来自于University of Notre Dame 的DBA表示,他正在试图通过数据库监控软件,找出SQL server的性能基准。

  • DBA必须掌握的数据库恢复管理技术

    如果没有备份副本,数据库管理员就无法还原数据库,所以DBA在恢复之前倾向于考虑备份是合乎逻辑的。 但是,对我来说,这种逻辑一直是错误的。

  • DBA也要和领导抢饭碗?

    数据库架构师Ziaul Mannan 认为,DBA有成为高管的潜在可能,而这种潜力在过去往往被忽视,他还将证明DBA技能到领导力的转变是可行的。

  • Oracle备份和恢复简史

    这些年来,Oracle数据库备份和恢复方式已经发生了重大变化,特别是在Recovery Manager(RMAN)功能有了进一步改善之后。