lianle

原谅在前面加了这么多标签，都有用！


目前最大的备份软件公司非Veritas公司莫属，Veritas的备份软件产品有Exec和netbackup两大类，exec为入门级产品，这里不作讨论。

netbackup（以后简称nb），我的总结是：“功能真他妈强，操作全要命令行”。

我认为Veritas的操作非常复杂，可Veritas的技术支持是这么解释的，“nb是一个企业级的备份软件，只需要在开始进行调试，调试好了就不需要再管了。所以调试时复杂就复杂吧”

monkey

veritas功能是比较强大，但是用很不方便，而且速度性能都不尽如人意，个人认为单从备份来讲，bakbone netvault比较好用！

lianle

更改一下，本贴主题为 “数据库备份之我见”

nb的最大特点是介质管理，但是在数据库备份上却没做什么事情，

以Oracle数据库备份为例，Vertias的一个Oracle Agent的价格和server license的价格相同，但Veritas做了什么呢：

1，提供一个通道，只要使用Oracle的rman工具备份通道为sbttape，数据就传送到veritas的介质管理器，由他来决定数据存放到什么位置。
2，定期执行备份脚本。

就为了一个链接却要掏这么多钱，简直是抢。

其他的备份软件我没试过，因此希望那位有经验说一下

[此贴子已经被作者于2003-11-27 16:56:26编辑过]

lianle

Veritas最然在数据库备份方面做得不多，但他写的关于数据库的文章还是不错的，文章是英文的，把翻译的部分分享给大家。


数据库
数据库就是结构化的数据仓库。人们时刻都在和数据打交道，如：存储在个人掌上电脑（PDA）中的数据、家庭预算电子数据表，等等。对于少量、简单的数据，如果它们与其它数据之间的关联较少或没有关联的情况下，他们可以简单的存放在文件中，如错误！未找到引用源。. 中描述的。当然如果所有的数据结构都很简单，那么数据库管理系统就没什么用了。
但是企业数据都是相关联的。如：职员表链接到名称和地址的记录，订单记录需要与库存信息相对应，海运记录需要与信用额度相对应，等等。通常来说，不可能使用普通的记录文件来管理大量的、复杂的系列数据，如：银行的客户数据，或者生产厂商的的生产控制数据。普通记录文件没有系统结构来系统的反映数据间的复杂关系，它也不能强制定义个别数据对象。
数据库管理系统
数据库管理系统(DBMSs)，或者数据库管理器,已经发展了近二十年，来解决上面提到的这些需求。数据库管理器是近似于文件系统的软件系统，通过它，应用程序和用户可以取得所需的数据。然而，它们又不象文件系统，它们定义了所管理的数据之间的结构和约束关系。并且，数据库管理器提供了一些基本的数据管理函数：
►        数据安全: 在商业上，数据库必须是一个可以存储数据的安全的地方。数据库管理器必须提供有效的备份和恢复能力，来确保在灾难和错误后，数据能够尽快的可以被应用所访问。
►        数据安全: 对于一个企业来说，它把关键的和重要的数据存放在数据库中，数据库管理系统必须能够防止未授权的数据访问。
►        数据共享: 一个数据库必须允许多个应用和用户同时进行数据访问，而且不影响数据的完整性。例如：如果两个用户试图同时修改同一条记录，两个修改操作都必须被处理，并且产生一个可理解的干净的结果。
►        数据组织: 基于文件的数据的主要优势就在于它利用了数据结构。数据库的结构使开发者避免了针对每一个应用都需要重新定义数据逻辑关系的过程。
数据库数据模型
数据库管理系统的发展已经经历了一个漫长复杂的过程。人们提出了许多数据模型，并一一实现。其中比较重要的三个就是：
►        分级模型: 在一个分级的数据库中，数据项间具有父项与子项的关系。例如：一个顾客的记录包括名称和地址信息，它可能就是一系列订单记录的父项，每个订单记录包含了关于这个订单的详细信息。
►        网络模型: 在一个网络数据库中，数据项之间有更多的相互关系。这些关系通常用来描述一个图形形状，或者网络中形成刀片结构的那些节点和它们之间的关系。
►        关系模型: 在关系型数据库中，数据项保存在行中，文件就象是一个表。关系被描述成不同数据表间的匹配关系。一个区别关系模型和网络及分级型数据库的重要一点就是数据项关系可以被动态的描述或定义，而不需要因为结构被改变而卸载然后重新加载数据库。
关系模型
早在1980年，数据库市场就被关系型数据库管理系统所占领。关系模型的成功并不在意料之外。这个模型基于一个可靠的基础，它可以简单并恰当的将数据项描述成为表（table）中的记录行(raw)。关系模型第一次广泛的推行是在1980年中，是因为一种标准的数据库访问程序语言被开发出来，它被称作结构查询语言（SQL）。
今天，成千上万使用关系型数据库的应用程序已经被开发出来，包括跟踪客户端处理的银行系统，仓库货物管理系统，客户关系管理(CRM)系统，以及人力资源管理系统。由于数据库保证了数据的完整性，企业通常将他们的关键业务数据存放在数据库中。因此保护数据库避免错误以及灾难已经成为企业所关注的重点。

lianle

数据库恢复
正规的数据库备份是最基本和有效的数据库容灾技术。数据库备份和恢复技术与我们在错误！未找到引用源。中讲述的文件系统的备份和恢复是不同的。
数据库事务
如果要明白备份恢复技术，明白数据库事务的种类是很有用的。一个事务就是一个事务活动所引起的一系列的数据库操作。例如，一个会计事务可能是由以下部分组成：
►        读取借方数据
►        减去借方记录中的借款数量
►        重写借方记录
►        读取贷方记录
►        在贷方记录上的数量加上从借方扣除的数量
►        重写贷方记录
►        写一条单独的记录来描述这次操作，以便日后审计
所有这些操作组成了一个事务，描述了一个业务动作。在上述例子中，无论借方的动作或是贷方的动作哪一个没有被执行，数据库都不会反映该业务执行正确。
数据库管理系统在数据库操作时强迫进行事务定义，这意味着或者一个事务定义的应用的全部操作结果都反映在数据库中，或者都没有反映在数据库中，即使数据库在事务执行过程中崩溃的情况下。
事务定义是关系数据库中最重要的关系之一。上述例子包含了两个数据库操作：从借方数据中扣除资金，并且在贷方记录中加入这部分资金。如果系统在执行事务的过程中崩溃，如果此时已修改完毕借方数据，但还没有修改贷方数据，资金就会在此时物化。把这两个步骤合并成一个事务命令，这样在数据库系统执行时，要么全部完成，要么全部不完成，但当只完成一步时，系统是不会对已作的这一步做出响应的。
数据库崩溃恢复
一个运行着数据库系统的计算机随时都可能宕机。然而“已借未贷”或“已贷未借”的情况都可能出现。当系统崩溃后重启时，数据库管理系统必须允许这种可能性的发生，也就是说，在磁盘数据文件中可能包含一些部分完成的事务，在应用能够访问数据库数据之前，这些必须全部被检出。
防止上述情况发生的基本技术就是保存一份连续日志，记录将做的和完成的操作。当需要修复损坏的数据库时，数据库系统重新应用这些日志，寻找那些将要执行但未完成的任务。如果任何类似的事务的已经在数据库中反映，这一定是颠倒的，并且数据库必须回滚。
使用这种日志重新应用的技术，数据库系统可以避免宕机所带来的已接受事务（应用已确认执行完毕的事务）的丢失。数据修复时，那些在宕机时处理结果还存在缓存中的已接受事务，结果会存放到磁盘文件中。未接受事务（还没有被应用确认的事务）会被回滚，消除它所带来的对其他数据的影响。为了帮助解释数据库日志如何工作，Figure 1-1描述了一个简单的数据库管理组件。

lianle

数据库备份中的一致性和实时性

一致性和实时性
一个一致性的数据库就是指数据处理响应完成了的数据库。例如：一个会计数据库，当它的记入借方与相应的贷方记录相匹配的情况下，它就是数据一致的。
一个实时的数据库就是指所有的事务全部执行完毕后才响应。如果一个正在运行数据库管理的系统崩溃了，而对事务的处理结果还存在缓存中而没有写入到磁盘文件中的情况，当系统重新启动时，系统数据就是非实时性的。
数据库日志被用来在灾难发生后恢复数据库时保证数据库的一致性和实时性。

lianle

数据库增量备份
数据库的不断增长和对可用性要求的提高，使数据库全备份在许多情况下无法完成。如同文件系统一样，如果在两次备份间只有少量的数据变化，数据库增量备份可以缩短数据库备份时间。如果只是变化了的数据被拷贝，可以节省备份时间和备份介质。与全备份类似，增量备份也可以是逻辑的或是物理的。
逻辑增量备份
归档数据库日志是逻辑数据库增量备份的一种方式。通过恢复一次数据库全备份和重新应用归档日志，可以将数据库恢复到归档的最新时刻。把全备份数据和所有的归档日志存放在一个安全的地方，是一个很有用处的恢复技术。
随着归档日志的堆积，恢复时间和对介质的占用都会随之增长。对于每一个企业，都有一个对增量恢复窗口的可容忍的极限。因此，增量备份策略应该包含定期的数据库全备份，以便经常建立新的基点。
一些数据库管理器可以在数据库正在运行时执行数据库逻辑增量备份。一个逻辑增量备份在开始时首先检测自上次备份后改变了的数据块的列表。这些块被读取并被传送到备份服务器。增量备份减少了全备份必须被执行的频率。使用这种技术，数据库恢复就可以是自动的，因为数据库管理器的恢复功能可以从以前的全备份和后来的增量备份创建一个较新的数据库映像。增量备份使数据库性能只是稍有加强，因为数据库管理器必须创建一个变化数据块的列表。
物理增量备份
包含数据库系列文件的文件系统的增量备份有效的创建了一个数据库的物理增量备份。但当一个数据库管理器刷新表中的一行数据时，只有包含这条数据的文件块改变了，其余的文件块并没有受到影响。然而针对文件的任何改变都会导致在增量备份中整个文件被拷贝，这种基于文件的增量备份通常等同于数据库全备份。如果数据库管理器或者备份程序能够识别在数据库文件中变化了的数据块，就可以只备份变化的数据块；有这么一种技术被称作数据块级增量备份。
在使用快速镜像不太现实的情况下，除使用更少的备份介质外，数据库增量备份能够减小备份窗口。一些数据库管理器能够执行透明的数据库物理增量备份和恢复，使对个别增量备份的管理降到最低。要完成一个基于块级别的备份的数据库恢复，首先应恢复最新的全备份，然后重新应用所有的后面的增量备份来恢复数据库映像。
恢复任何的增量备份都需要花费时间。数据库管理员通常制定周期全备份计划，以便定期改变新的数据恢复基点，限制最高的增量跳越数量（和最糟糕情况下的恢复时间）。一些备份程序可以实现被称为“合成全备份”的功能，这是通过第二台服务器上的增量来实现的。这些合成全备份在每一次增量的恢复后都会产生一个新的基点。

lianle

当被剥离的镜像卷连接到存储网络中，可使用一个额外的服务器来进行数据的拷贝。因为使用了独立的存储设备和服务器资源，因此对数据库应用性能没有任何影响。唯一的缺点是，当基于被剥离的镜像卷的数据库备份拷贝完成后，镜像卷需要重新连接到数据库存储卷中。重新同步所有的I/O会影响应用的I/O。镜像技术可以记录所有在剥离镜像卷后改变了的数据，在镜像卷重新接入后快速同步数据，这种技术使同步对应用的影响降到最低。图1-4使用流程图描述了脱离主机的备份方式。流程图同样强调了快照可以在运行着数据库的服务器上进行备份。

lianle

数据库备份技术
就如前面对恢复作用的描述，一个数据库的数据库备份必须必须是一个数据库的完整的映像，在这个映像的时间点上，没有部分完成的事务存在。这可以通过数据库的离线备份来实现，因为在这种情况下，没有事务需要处理。这种方式的缺点在于，在备份过程中，没有应用能够使用数据库。数据库在线的时候也可以进行备份，在这种情况下，备份程序要确保不管数据访问多么活跃，都能够得到一个完整的数据拷贝。
离线数据备份
如果备份时数据库不可以被应用所访问，那么我们称这种备份为离线备份或冷备份。冷备份可以通过关闭数据库然后进行文件备份来实现。离线数据库备份是简单的，也是被认为有效的备份技术。但是逐渐的，企业发现把他们的数据库停下来，然后进行备份，这种方式完全不切实际。而且，在一些老的数据库管理系统中，冷备份拷贝不能用来进行前滚，因为它们与数据库日志不同步。在新的数据库设计中，已经解决了冷备份拷贝与数据库日之间的同步问题，所以前面的问题也就逐渐不成为问题了。
在线数据库备份
现在大多数的数据库都可以在应用进行数据访问时进行数据备份。在备份活跃数据库时有两种基本技术，被称作逻辑的和物理的在线分别备份。
大多数数据库管理系统都支持逻辑在线备份。例如：被包含在Oracle数据库的RMAN工具和Sybase数据库的“dump database”命令。逻辑在线备份之所以这么命名，是因为它拷贝了数据库的逻辑单元，而不是存储设备列表或是存储逻辑单元的文件。逻辑数据库备份工具通常和恢复、修复工具放在一起，因此产生有问题备份的几率较小。逻辑数据库备份的主要缺点就是他无法利用存储设备的快照技术来减少对应用的影响。因为在一个逻辑数据库备份的过程中，系统性能会大大的降低，因此它对总是处在活跃状态的数据库并不合适。
在线数据库备份也可以通过物理的备份数据库底层所包含的文件来实现。数据库的数据文件并不是随时都可以进行拷贝的，因为数据库始终在不断的刷新这些文件。一个文件的拷贝包含有非全部完整事务的概率很高，而且也不要期望通过数据库修复来恢复数据的一致性。
要确保一个具有一致性的系列文件备份，数据库必须处于一个静止状态，没有事务提交，也没有缓存的数据需要写到存储中。当备份结束后，数据库可以被重新激活。当然在数据库备份时，数据库时不可用的，这样的结果与离线数据备份基本相同。
一些文件系统和卷管理器支持数据快照。如果可以制作一个基于数据库所包含文件的快照，那么数据库只需要在快照初始化的一瞬间是静止的即可。一旦快照初始化完毕，数据库就可以重新提供访问能力。快照使备份可以进行在应用正在访问“实际”的数据库的过程中。因此，物理数据库备份可以是在(近)线的，而且能够保证数据库拷贝的一致性。
数据库静止状态
不同的数据库支持不同的备份技术。例如：Oracle，将表空间（一组表）置于在线的备份模式。这样的一份备份数据就可能不一致，因为数据库会在备份模式下会不断的刷新数据。然而恢复却可以是一致的，因为在备份过程中，额外的信息被数据库的管理日志记录下来。重新应用日志记录了数据库在备份状态下的变化，并将它恢复成一致的状态。
其它的数据库管理，包括Sybase ASE和DB2，会暂时的挂起所有事务并且将缓存保存，这样一个基于快照的数据库所包含文件的拷贝就是一个一致性的数据库拷贝。
包含了卷管理和文件系统快照的物理数据库备份技术是一种非常强大的技术，因为它基本消除了应用不能进行数据访问的备份窗口时间。例如：数据库可以将数据直接或间接的存储在镜像的逻辑卷上。要进行备份的情况下，数据库管理员可以将数据库暂时静止，将镜像卷与存储分离，然后重新激活数据库。被分离的镜像卷包含了一个一致的数据拷贝，可以通过它完成一个数据库复制。这种情况下的应用不能访问数据库的备份窗口只有几秒钟或几分钟。图1-3描述了这种剥离镜像的在线备份方式。

lianle

文件系统缓存和数据库恢复
如果使用文件作为数据库的数据存储方式会给我们的讨论增加一些额外的复杂性，因为文件管理系统有它自己的缓存。如果一个数据库系统在宕机后立刻重新启动，那么它所包含的文件可能并没有实时刷新到存储中，这是由于在系统宕机时，文件系统的缓存没有写入到存储的原因 。在这种情况下，数据库恢复进程必须重新应用数据日志刷新。也就是说，在系统宕机的情况下已接受事务也不会丢失。
归档日志：
长时间的数据库恢复
大多数的数据库都支持数据库日志归档，支持企业保存一个长时间的数据刷新历史。如果所有的基于一次全备份时间点之后的归档数据全部可用，那么就可以通过以下步骤恢复成为一个最新的数据库。
►        恢复备份拷贝
►        在已经恢复的数据库上重新应用所有的归档日志。
►        在已经恢复的数据库上重新应用数据库日志。
这也许是一个灾难后完全丧失服务能力数据中心的唯一恢复数据方法。在这个工作过程步骤中，数据库全备份数据和归档日志必须快速的传送到灾难恢复中心。为了实现完全的实时数据库恢复，镜像或复制当前的数据库日志到恢复中心也是必需的，就如我们在错误！未找到引用源。中描述的那样。