Oracle OS备份了解

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

　　理解备份需求

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

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

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

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

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

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

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

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

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

　　备份副本保存多长时间？

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

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

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

　　备份类型

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

　　这里每一种类型都有细微区别，它们有不同的用途。最常用的三种备份类型是：完全备份（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需要定期验证备份，而且应该考虑至少每一年左右执行一次全面服务器恢复测试。