| UML软件工程组织 | |||
| |
|||
|
|||
数据库备份之我见
作者：gulibin 文章来源：blog.51cto.com
目前最大的备份软件公司非Veritas公司莫属，Veritas的备份软件产品有Exec和netbackup两大类，exec为入门级产品，这里不作讨论。netbackup（以后简称nb），我的总结是：“功能真他妈强，操作全要命令行”。我认为Veritas的操作非常复杂，可Veritas的技术支持是这么解释的，“nb是一个企业级的备份软件，只需要在开始进行调试，调试好了就不需要再管了。 所以调试时复杂就复杂吧” nb的最大特点是介质管理，但是在数据库备份上却没做什么事情，以Oracle数据库备份为例，Vertias的一个Oracle Agent的价格和server license的价格相同，但Veritas做了什么呢： 1，提供一个通道，只要使用Oracle的rman工具备份通道为sbttape，数据就传送到veritas的介质管理器，由他来决定数据存放到什么位置。 2，定期执行备份脚本。 Veritas最然在数据库备份方面做得不多，但他写的关于数据库的文章还是不错的，文章是英文的，把翻译的部分分享给大家。 数据库 数据库就是结构化的数据仓库。人们时刻都在和数据打交道，如：存储在个人掌上电脑（PDA）中的数据、家庭预算电子数据表，等等。对于少量、简单的数据，如果它们与其它数据之间的关联较少或没有关联的情况下，他们可以简单的存放在文件中，如错误！未找到引用源。.
中描述的。当然如果所有的数据结构都很简单，那么数据库管理系统就没什么用了。 数据库管理系统 数据库管理系统(DBMSs)，或者数据库管理器,已经发展了近二十年，来解决上面提到的这些需求。数据库管理器是近似于文件系统的软件系统，通过它，应用程序和用户可以取得所需的数据。然而，它们又不象文件系统，它们定义了所管理的数据之间的结构和约束关系。并且，数据库管理器提供了一些基本的数据管理函数：
数据库数据模型 数据库管理系统的发展已经经历了一个漫长复杂的过程。人们提出了许多数据模型，并一一实现。其中比较重要的三个就是：
关系模型 早在1980年，数据库市场就被关系型数据库管理系统所占领。关系模型的成功并不在意料之外。这个模型基于一个可靠的基础，它可以简单并恰当的将数据项描述成为表（table）中的记录行(raw)。关系模型第一次广泛的推行是在1980年中，是因为一种标准的数据库访问程序语言被开发出来，它被称作结构查询语言（SQL）。 数据库备份中的一致性和实时性 一致性和实时性 一个一致性的数据库就是指数据处理响应完成了的数据库。例如：一个会计数据库，当它的记入借方与相应的贷方记录相匹配的情况下，它就是数据一致的。 一个实时的数据库就是指所有的事务全部执行完毕后才响应。如果一个正在运行数据库管理的系统崩溃了，而对事务的处理结果还存在缓存中而没有写入到磁盘文件中的情况，当系统重新启动时，系统数据就是非实时性的。 数据库恢复 正规的数据库备份是最基本和有效的数据库容灾技术。数据库备份和恢复技术与我们在错误！未找到引用源。中讲述的文件系统的备份和恢复是不同的。 数据库事务 如果要明白备份恢复技术，明白数据库事务的种类是很有用的。一个事务就是一个事务活动所引起的一系列的数据库操作。例如，一个会计事务可能是由以下部分组成：
所有这些操作组成了一个事务，描述了一个业务动作。在上述例子中，无论借方的动作或是贷方的动作哪一个没有被执行，数据库都不会反映该业务执行正确。 数据库管理系统在数据库操作时强迫进行事务定义，这意味着或者一个事务定义的应用的全部操作结果都反映在数据库中，或者都没有反映在数据库中，即使数据库在事务执行过程中崩溃的情况下。 事务定义是关系数据库中最重要的关系之一。上述例子包含了两个数据库操作：从借方数据中扣除资金，并且在贷方记录中加入这部分资金。如果系统在执行事务的过程中崩溃，如果此时已修改完毕借方数据，但还没有修改贷方数据，资金就会在此时物化。把这两个步骤合并成一个事务命令，这样在数据库系统执行时，要么全部完成，要么全部不完成，但当只完成一步时，系统是不会对已作的这一步做出响应的。 数据库崩溃恢复 一个运行着数据库系统的计算机随时都可能宕机。然而“已借未贷”或“已贷未借”的情况都可能出现。当系统崩溃后重启时，数据库管理系统必须允许这种可能性的发生，也就是说，在磁盘数据文件中可能包含一些部分完成的事务，在应用能够访问数据库数据之前，这些必须全部被检出。 防止上述情况发生的基本技术就是保存一份连续日志，记录将做的和完成的操作。当需要修复损坏的数据库时，数据库系统重新应用这些日志，寻找那些将要执行但未完成的任务。如果任何类似的事务的已经在数据库中反映，这一定是颠倒的，并且数据库必须回滚。 使用这种日志重新应用的技术，数据库系统可以避免宕机所带来的已接受事务（应用已确认执行完毕的事务）的丢失。数据修复时，那些在宕机时处理结果还存在缓存中的已接受事务，结果会存放到磁盘文件中。未接受事务（还没有被应用确认的事务）会被回滚，消除它所带来的对其他数据的影响。为了帮助解释数据库日志如何工作，Figure 1-1描述了一个简单的数据库管理组件。 文件系统缓存和数据库恢复 如果使用文件作为数据库的数据存储方式会给我们的讨论增加一些额外的复杂性，因为文件管理系统有它自己的缓存。如果一个数据库系统在宕机后立刻重新启动，那么它所包含的文件可能并没有实时刷新到存储中，这是由于在系统宕机时，文件系统的缓存没有写入到存储的原因 。在这种情况下，数据库恢复进程必须重新应用数据日志刷新。也就是说，在系统宕机的情况下已接受事务也不会丢失。 归档日志： 长时间的数据库恢复 大多数的数据库都支持数据库日志归档，支持企业保存一个长时间的数据刷新历史。如果所有的基于一次全备份时间点之后的归档数据全部可用，那么就可以通过以下步骤恢复成为一个最新的数据库。
这也许是一个灾难后完全丧失服务能力数据中心的唯一恢复数据方法。在这个工作过程步骤中，数据库全备份数据和归档日志必须快速的传送到灾难恢复中心。为了实现完全的实时数据库恢复，镜像或复制当前的数据库日志到恢复中心也是必需的，就如我们在错误！未找到引用源。中描述的那样。 数据库备份技术 就如前面对恢复作用的描述，一个数据库的数据库备份必须必须是一个数据库的完整的映像，在这个映像的时间点上，没有部分完成的事务存在。这可以通过数据库的离线备份来实现，因为在这种情况下，没有事务需要处理。这种方式的缺点在于，在备份过程中，没有应用能够使用数据库。数据库在线的时候也可以进行备份，在这种情况下，备份程序要确保不管数据访问多么活跃，都能够得到一个完整的数据拷贝。 离线数据备份 如果备份时数据库不可以被应用所访问，那么我们称这种备份为离线备份或冷备份。冷备份可以通过关闭数据库然后进行文件备份来实现。离线数据库备份是简单的，也是被认为有效的备份技术。但是逐渐的，企业发现把他们的数据库停下来，然后进行备份，这种方式完全不切实际。而且，在一些老的数据库管理系统中，冷备份拷贝不能用来进行前滚，因为它们与数据库日志不同步。在新的数据库设计中，已经解决了冷备份拷贝与数据库日之间的同步问题，所以前面的问题也就逐渐不成为问题了。 在线数据库备份 现在大多数的数据库都可以在应用进行数据访问时进行数据备份。在备份活跃数据库时有两种基本技术，被称作逻辑的和物理的在线分别备份。 大多数数据库管理系统都支持逻辑在线备份。例如：被包含在Oracle数据库的RMAN工具和Sybase数据库的“dump database”命令。逻辑在线备份之所以这么命名，是因为它拷贝了数据库的逻辑单元，而不是存储设备列表或是存储逻辑单元的文件。逻辑数据库备份工具通常和恢复、修复工具放在一起，因此产生有问题备份的几率较小。逻辑数据库备份的主要缺点就是他无法利用存储设备的快照技术来减少对应用的影响。因为在一个逻辑数据库备份的过程中，系统性能会大大的降低，因此它对总是处在活跃状态的数据库并不合适。 在线数据库备份也可以通过物理的备份数据库底层所包含的文件来实现。数据库的数据文件并不是随时都可以进行拷贝的，因为数据库始终在不断的刷新这些文件。一个文件的拷贝包含有非全部完整事务的概率很高，而且也不要期望通过数据库修复来恢复数据的一致性。 要确保一个具有一致性的系列文件备份，数据库必须处于一个静止状态，没有事务提交，也没有缓存的数据需要写到存储中。当备份结束后，数据库可以被重新激活。当然在数据库备份时，数据库时不可用的，这样的结果与离线数据备份基本相同。 一些文件系统和卷管理器支持数据快照。如果可以制作一个基于数据库所包含文件的快照，那么数据库只需要在快照初始化的一瞬间是静止的即可。一旦快照初始化完毕，数据库就可以重新提供访问能力。快照使备份可以进行在应用正在访问“实际”的数据库的过程中。因此，物理数据库备份可以是在(近)线的，而且能够保证数据库拷贝的一致性。 数据库静止状态 不同的数据库支持不同的备份技术。例如：Oracle，将表空间（一组表）置于在线的备份模式。这样的一份备份数据就可能不一致，因为数据库会在备份模式下会不断的刷新数据。然而恢复却可以是一致的，因为在备份过程中，额外的信息被数据库的管理日志记录下来。重新应用日志记录了数据库在备份状态下的变化，并将它恢复成一致的状态。 其它的数据库管理，包括Sybase ASE和DB2，会暂时的挂起所有事务并且将缓存保存，这样一个基于快照的数据库所包含文件的拷贝就是一个一致性的数据库拷贝。 包含了卷管理和文件系统快照的物理数据库备份技术是一种非常强大的技术，因为它基本消除了应用不能进行数据访问的备份窗口时间。例如：数据库可以将数据直接或间接的存储在镜像的逻辑卷上。要进行备份的情况下，数据库管理员可以将数据库暂时静止，将镜像卷与存储分离，然后重新激活数据库。被分离的镜像卷包含了一个一致的数据拷贝，可以通过它完成一个数据库复制。这种情况下的应用不能访问数据库的备份窗口只有几秒钟或几分钟。图1-3描述了这种剥离镜像的在线备份方式。 当被剥离的镜像卷连接到存储网络中，可使用一个额外的服务器来进行数据的拷贝。因为使用了独立的存储设备和服务器资源，因此对数据库应用性能没有任何影响。唯一的缺点是，当基于被剥离的镜像卷的数据库备份拷贝完成后，镜像卷需要重新连接到数据库存储卷中。重新同步所有的I/O会影响应用的I/O。镜像技术可以记录所有在剥离镜像卷后改变了的数据，在镜像卷重新接入后快速同步数据，这种技术使同步对应用的影响降到最低。图1-4使用流程图描述了脱离主机的备份方式。流程图同样强调了快照可以在运行着数据库的服务器上进行备份。 数据库增量备份 数据库的不断增长和对可用性要求的提高，使数据库全备份在许多情况下无法完成。如同文件系统一样，如果在两次备份间只有少量的数据变化，数据库增量备份可以缩短数据库备份时间。如果只是变化了的数据被拷贝，可以节省备份时间和备份介质。与全备份类似，增量备份也可以是逻辑的或是物理的。 逻辑增量备份 归档数据库日志是逻辑数据库增量备份的一种方式。通过恢复一次数据库全备份和重新应用归档日志，可以将数据库恢复到归档的最新时刻。把全备份数据和所有的归档日志存放在一个安全的地方，是一个很有用处的恢复技术。 随着归档日志的堆积，恢复时间和对介质的占用都会随之增长。对于每一个企业，都有一个对增量恢复窗口的可容忍的极限。因此，增量备份策略应该包含定期的数据库全备份，以便经常建立新的基点。 一些数据库管理器可以在数据库正在运行时执行数据库逻辑增量备份。一个逻辑增量备份在开始时首先检测自上次备份后改变了的数据块的列表。这些块被读取并被传送到备份服务器。增量备份减少了全备份必须被执行的频率。使用这种技术，数据库恢复就可以是自动的，因为数据库管理器的恢复功能可以从以前的全备份和后来的增量备份创建一个较新的数据库映像。增量备份使数据库性能只是稍有加强，因为数据库管理器必须创建一个变化数据块的列表。 物理增量备份 包含数据库系列文件的文件系统的增量备份有效的创建了一个数据库的物理增量备份。但当一个数据库管理器刷新表中的一行数据时，只有包含这条数据的文件块改变了，其余的文件块并没有受到影响。然而针对文件的任何改变都会导致在增量备份中整个文件被拷贝，这种基于文件的增量备份通常等同于数据库全备份。如果数据库管理器或者备份程序能够识别在数据库文件中变化了的数据块，就可以只备份变化的数据块；有这么一种技术被称作数据块级增量备份。 在使用快速镜像不太现实的情况下，除使用更少的备份介质外，数据库增量备份能够减小备份窗口。一些数据库管理器能够执行透明的数据库物理增量备份和恢复，使对个别增量备份的管理降到最低。要完成一个基于块级别的备份的数据库恢复，首先应恢复最新的全备份，然后重新应用所有的后面的增量备份来恢复数据库映像。 恢复任何的增量备份都需要花费时间。数据库管理员通常制定周期全备份计划，以便定期改变新的数据恢复基点，限制最高的增量跳越数量（和最糟糕情况下的恢复时间）。一些备份程序可以实现被称为“合成全备份”的功能，这是通过第二台服务器上的增量来实现的。这些合成全备份在每一次增量的恢复后都会产生一个新的基点。 从备份恢复数据库 通过正规备份，并且快速的将备份介质运送到安全的地方，数据库就能够在大多数的灾难中得到恢复。恢复是文件的使用是从一个基点的数据库映像开始，到一些综合的备份和日志。由于不可预知的物理灾难，一个完全的数据库恢复(重应用日志)可以使数据库映像恢复到尽可能接近灾难发生的时间点的状态。对于逻辑灾难，如：人为破坏或者应用故障等，数据库映像应该恢复到错误发生前的那一点。 在一个数据库的完全恢复过程中，基点后所有日志中的事务被重新应用，所以结果就是一个数据库映像反映所有在灾难前已接受的事务，而没有被接受的事务则不被反映。为了恢复数据库误操作等错误，完全的恢复时不合适的，因为如果重新应用所有事务，错误就会重复。数据库恢复应用程序允许管理员停止日志前滚在错误发生前一点。数据库恢复可以恢复到错误发生前的最后一个时刻。 检验数据库备份 大多数的企业都会定期地对他们的数据库进行备份，但是却没能经常地对数据库备份进行检验。数据库备份会由于以下各种原因而变得无效：
从某种意义而言，无效的数据库备份比根本不做备份的情况更糟，因为无效的数据库备份会造成一种安全的假象。 因此，检验数据库备份是一项非常重要的工作，尤其是在进行了自动备份进程之后或是在数据库结构改变之后。即使是没有任何改变发生，定期进行检验也是必需的，例如可以定期地检测损坏的介质或磁带驱动器等等。 为了将检验工作对数据库生产运行的影响冲突降至最低，备份的检验工作需要使用备用资源。一个正在用于检验修复备份的数据库应该带有一个备用数据库标识符或服务器名称以免客户端会将信息错误地发送给检验数据库。检验内容应该既包括使用全部的归档日志的数据库恢复资源，也包括使用厂商提供工具进行数据库一致性的检验。 管理数据库日志 对于容灾而言，数据库备份应当存贮在远离数据库的地方。为了达到最优容灾状态，在灾难发生后能够容易地获取数据库日志也是非常必要的。数据库归档日志通常保存在备份储存的地点。数据库管理员必须在数据库实时恢复和资源占用量两者之间找到平衡，从而决定进行数据库日志归档的频率。过多地进行归档可以降低数据损失的潜在危险，但是浪费了更多的进程和I/O资源，很有可能增加了处理的响应时间。过少地进行归档可以降低资源的平均占用量，但是延长了两次归档的间隔时间，很有可能导致不能做到精确的实时恢复。 如果一个数据库和它的联机日志被损坏了，那么即使马上进行了严密的数据库备份和日志归档，数据也极有可能丢失。因此，一个完整的数据库融灾策略的一个重要部分就是对联机的数据库日志进行复制，这样在进行修复处理时就可以及时利用这些复制的内容准确无误地修复数据库。联机数据库日志可以通过有限的距离进行镜像。(错误！未找到引用源。).如果距离过长，数据库管理员可以通过多路转接技术或者通过企业网络同时进行本地和远处的日志拷贝。多路转接技术通常比镜像和低水平复制（如数据卷）的速度要慢一些，因此如果可以的话要尽量选择后一种方式。 最高级别的数据库实时恢复是在每次事务提交的之前同步进行数据库日志的传输和归档。换句话说，必须要在日志已经被转移到另外地点后，才进行事务的提交。显而易见，这种选择执行起来的代价是非常昂贵的，因而在实践中较少采用。 数据库复制 周围环境的灾难，例如：地震、洪水，或者暴乱会使整个数据中心及周围环境彻底丧失数据服务的能力。为了恢复一个灾难中的数据库，必须有一个灾难破坏范围之外的一个数据的冗余拷贝，并且当恢复中心数据恢复完毕后，必须可以响应客户端的请求。 使用传输日志方法的复制 保证数据库可恢复的环境容灾的最基本挑战就是如何保证容灾地点具有最新的数据。或许实现这种状态的最简单办法就是在数据中心与容灾地点间物理的传送归档日志，例如，使用快递或运输服务。在恢复地点，日志被备份数据库（有的叫做备用数据库）重新应用来实现数据“刷新”。对于应用来说，如果可以容忍一整天的数据丢失，那么这种简单的方法也许就足够了。它的主要缺点就是数据刷新和重路由客户端请求的劳动强度比较高，很容易出现人为错误。 对于简单应用和小型数据库，日志传输和数据库刷新技术可以通过在网络上执行定期的日志传送和刷新任务来自动完成。 数据库管理器复制 今天，大多数数据库管理器支持精密的实施复制，允许例如一对多、双向的复制。也可以是数据库子集的复制，只将感兴趣的数据复制到目标端。在分布式数据库最初设计时，数据库管理器复制就可以用来实现容灾复制。 数据库复制需要在主站点和恢复站点间有一个高性能网络的连接，但即使这样也不能实时同步，这意味着在数据库完全将数据反映到备用数据库有一个时间延迟。一些数据库支持同步复制，虽然解决了上面的问题，但是它明显减低了主数据库的性能，因为只有当所有的复制任务全部结束后，数据库才能继续接收数据。 针对数据库的存储复制 数据库复制要求具有专门的数据库管理技术。额外的，一些基于数据库的信息服务在数据库之外存储了额外的数据。为了实现灾难恢复，所有的应用信息都必须复制到远程站点。存储复制是针对数据库复制的一个简单可行的办法，它可以将数据库数据和其它数据全部从数据中心复制到恢复站点。 数据库的内容可以在卷一级或者文件一级进行复制。稳定的、高性能的文件系统复制也相当优秀。可靠的高性能卷复制能够使远程复制数据文件、在线日志和归档日志变得非常简单。如果所有的数据文件、日志文件，及其它的辅助数据都存放在一个独立的文件系统或独立的卷中，复制就会变得非常简单。 卷管理器对数据库恢复的非常有利，原因在于它在数据中心与容灾站点执行同样顺序的操作。如果没有这个特点，它的数据不能够保证与实际数据库先前的状态一致，也就是说复制就不能作为数据库恢复的基础。 复制的延时 无论数据库复制还是存储复制，都会将认为无操作和应用错误复制到恢复端。例如，在主站点错误的删除了一个表，那么恢复中心也同会删除，因此使用复制无法纠正错误。 如果在数据中心与恢复中心的数据刷新上存在一定的可配制的延时，数据库复制就可以用来一些逻辑错误。例如，如果复制日志在应用到备用数据库前保留一小时，而逻辑错误在一小时之内被发现（通常是这样），这样错误还没有反映到复制数据库中。可以立即将复制停止，然后可以使用备用数据库恢复主数据库。 全局群集管理 因为更加坚固，在群集上，数据库应用可以同时运行在主站点和备用站点。在一个单独的数据中心内两个或更多的群集计算机可以通过一个大范围的网络连接成全局群集，他们是一个平等的高可用系统。当配制了多个恢复站点，或者一个恢复站点复制到第二个恢复站点，可以使用全局群集进行复杂的管理。 在错误切换的复杂性上和站点切换操作的限制性上，全局群集不同于本地群集。与本地群集相比，全局群集的错误切换往往不是自动的，管理员的决定通常需要经过严肃的考虑。全局群集的任务就是方便的提供一个分布的高可用服务器的全局的视图，并且可以通过一个单独的点来进行控制。 概要：数据库恢复层次 下面列出的数据库恢复技术是按照他们所能够提供的保护能力的顺序列出的，也同时是使用他们所需要的资金，方便程度，和技术复杂性的排列顺序。每一种技术都必须与他前面的技术共同使用。例如，磁盘镜像必须伴随着数据库备份和日志归档。
对于希望恢复时间（RTO）时间在几个小的内的企业，正规的数据库备份和日志归档也许就能满足。数据库备份和归档日志应该被保存在离数据中心有一定距离的地方。高级的备份软件的特性，如自动的定期的块增量备份可以减少管理成本，缩短备份窗口，以及最小化恢复时间。 通过简单的镜像硬件和网络，镜像数据库存储dada减少了因为硬件故障所引起的数据库停机。也可以通过剥离镜像的备份提高数据库的可用性。 可以通过群集技术提高数据库级信息服务的可用性。一个本地群集可以使由于系统的单点而出现故障的可能降到最小。当错误引起临时的损耗，服务恢复时自动的。在共享数据的群集中，损耗窗口可以为零。在群集中，备份可以运行在导入了数据库服务器镜像数据的辅助服务器上。 为防止站点实效而进行的灾难恢复中，数据库必须复制到远程站点。数据库复制的最简单方法就是将归档日志传送到远端，然后在备用服务器上重新应用。这种技术丢失的数据数量是固定的。不能容忍在灾难中丢失数据的企业应该使用数据库或存储复制。 最高的数据库可用性应该使用全局群集来完成，它在多个互相连接的站点中调整数据库和应用的可用程度。 弹性数据库通过不同方法使用冗余拷贝。数据库可以通过额外的拷贝提高访问性能。存储数据库数据的磁盘可以被镜像来提高弹性。实时备份可以用来避免灾难和故障。事务日志可以使导致数据错误的时间前滚。最后，完全的数据镜像可以在远端保存一份数据来避免灾难。高级的数据库管理器可以自行分发它们所管理的数据以提高数据库弹性和性能。 就目前常见的数据库备份软件，如果数据库备份要求数据库在线进行备份，通常要求数据库处于归档模式，而数据库如果处于归档模式，那么一，影响速度，二，一旦归档空间被占满，数据库就会停止，直到有新的归档空间。
一个理论，在数据库的底层，也就是使用磁盘阵列进行数据备份，当然磁盘阵列不具备备份功能，但是可以使用复制、镜像等功能进行备份，或者在主机与存储键使用虚拟存储，利用虚拟存储的俄外功能进行备份，但是备份下来的数据可不可用没有经过实际的环境测试，我的模拟环境是没有问题的。据厂家讲，有可能造成数据库的数据文件时间点不一致，即使修复也不一定成功。 但是，此时的备份状态应该与突然断电的状态相同，难道数据库在突然断电的情况下有可能导致再也无法启动吗？ 希望那个有实际数据库操作经验的dx解答。 国内有一家dsg公司，制作了一个oracle的备份软件，号称可在非归档模式下进行数据库备份，听说很不错，但我没有用过，不知效果怎么样。 |
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
