1 前言

ClearCase在IT软件开发公司中作为配置管理平台被使用时，由于存放着大量重要IT项目数据，所以许多公司愈来愈重视ClearCase数据的备份保存。因此本文以<<ClearCase Administrator’s Guide>>中的第10章为依据和引用，在翻译的基础之上对常见的ClearCase备份策略进行阐述。

2 ClearCase数据的备份

ClearCase管理人员重要任务就是定期备份数据。管理员在针对ClearCase VOB和View（视图）进行备份时，不仅应该考虑VOB和View有其特殊的备份和恢复特性，而且在UCM（统一变更管理）方式使用ClearCase的环境中，Vob之间或者VOB同ClearQuest Database之间有着紧密的数据相关性，备份时应该尤其给予重视，本文会说明如何在保证数据相关性的基础上进行备份。

注意：在本文的示例中，关于介绍使用tar进行数据拷贝时，应确保所使用tar版本能够拷贝目录中的所有文件而不管其文件大小。如果tar没能拷贝所有文件，则备份将会失败。

2.1 备份工具的要求

Vob和View的数据在物理上看都是普通文件和目录，它们可以使用常用的文件备份工具来备份，备份工具需要具有下面几个特征：

• 能够备份超大文件。最大文件的大小受操作系统和存储设备的限制，在VOB的schema 54版本中可以支持超过2GB的文件。确保备份工具可以支持这样的大文件。
• 能够保存NTFS ACLs。当Vob和View存储在Windows平台上的NTFS文件系统中，VOB和View的NTFS ACL是很重要的，VOB和View也可存储在FAT文件系统中(不推荐),备份工具应能够完整的保存NTFS ACL信息。
• 能够备份处于打开状态中的文件。在ClearCase所有支持的平台上，即使VOB被lock住，Vob server仍然可以读取和写入Vob数据库。（在lock住Vob后，clearcase自身的程序和服务仍可以读取VOB数据库，除非将Clearcase的服务停止。）所以备份工具应能够备份处于打开读取状态的文件。许多系统工具如copy和xcopy并没有这种能力，因此不要使用这种工具。
• 保存文件访问时间。在linux和unix平台上，tar常用于系统的备份，但会重置文件时间，对于VOB，文件最后访问时间会影响对DO（Derived Object）和存储池（Cleartext storage pool）的清洗（scrubber），那些需要清洗的文件就不会被清理掉，对于这些平台上VOB的备份，cpio是不错的选择(linux和unix平台)。

2.2 VOB备份策略

进行Vob备份前必须考虑的要点：

备份所有必需的数据；Vob必须在加锁(lock)的状态下备份，加锁的Vob会阻止数据变更（例如check-in）的写入。如果VOB服务不能定期停机，应仔细考虑备份策略，尽量减小锁住Vob的时间。在有管理Vob的环境里，这些有着超连接（hyperlink）的Vob必须同时备份与恢复。同样，在ucm集成ClearQuest的环境中，PVob与ClearQuest的Database中存在着很多关联，需要制定详细的备份和恢复计划。建议在制定备份策略时，首先知晓VOB存储目录的结构。

2.2.1 常规备份还是快照备份（snapshot backup）

常规备份是指应用备份工具备份VOB服务器上的物理目录， 使用快照备份需要使用 Vob_snapshot工具，这种备份可以减少Vob加锁的时间。

常规备份是指首先应对Vob加锁，备份整个Vob存储目录，最后在Vob解锁。Vob必须在备份过程中处于锁定状态。如果备份工具不能正常备份这些处于写入的文件，则需要停止 Clearcase服务后再进行备份。在Vob处于锁定状态时，会阻止所有的检出(check-out)，检入(check-in)以及其他影响到Vob数据的操作。这包括UCM中deliver和rebase操作，这些都需要merge。VOB处于加锁状态时，开发人员可以在已经checkout或hijack（仅适用于快照和Web视图）的文件版本上工作。Clearmake和Omake在Vob处于锁定状态时处于休眠状态并定时重试。详细的设置可以查看Clearmake 的命令行参考手册。

常规备份特点：

• 当clearcase的服务停止时，在该服务器上的所有vob和view都将不可用；
• 当备份至其他的物理设备时，本机不需要额外的磁盘空间；VOB的database与存储池同时备份与恢复，所以不会有数据的丢失。

快照备份是指在加锁状态下仅备份VOB database目录，其他目录在非锁定状态下备份，这样可显著减少加锁VOB的时间，尤其适用于特别大的VOB时使用这种方法备份。Vob_snapshot可以简单的配置成Clearcase任务,计划定期执行。

Snapshot的备份特点：

• 必须使用能够拷贝处于打开状态的文件的备份工具。锁定Vob，执行完Vob_snapshot后，解锁Vob，备份VOB中的其他存储目录。如果在备份过程中有用户在写入，则在恢复后可能会有数据的丢失；
• 需要更多的存储空间。snapshot备份过程中会把Vob db目录拷贝在本地磁盘中，另外，每个Vob的source pool容器中的数据被新的版本信息取代时，会多保留30分钟。这样在Vob恢复后，可以提高使用checkVob 同步Vob database和storage pool成功的几率。恢复过程复杂；
• 由于Vob storage pool和Vob database是在不同时间备份。因此在恢复后要进行同步，尤其是在进行snapshot与备份其他storage pool的间隔过程中，如果有DO和元素版本的增加或删除，则必须用checkVob解决；
• 恢复时可能会有数据丢失。如果恢复的storage pool比database旧，则恢复后会有一些数据丢失。如果恢复的storage pool比database更新，database会不包括新增加文件和版本的参考信息。详情参阅checkVob -force –fix命令说明。

注意：不存储部件(component)的PVOB没有数据信息存储在pool中，它可以使用Vob_snapshot进行备份且不会有数据的丢失。所有snapshot备份方式更适合备份此类PVOB。

2.3 应用Vob_snapshot进行备份

使用snapshot进行备份，首先要运行Vob_snapshot_setup，这个命令会安排在VOB中定期执行vob_snapshot操作（默认为每天），更加详尽的信息需要查看Vob_snapshot_setup和Vob_snapshot的命令行参考手册。当设定某些Vob采用快照备份时，必须进行连续的操作以确保整个Vob备份的完整性。 连续操作：

• 备份整个VOB存储目录，包括可能存在的远程storage pool，尽可能在Vob_snapshot一完成后进行，此备份不需要锁定VOB，如果能够在Vob_snapshot完成后的30分钟内完成备份，则在恢复时一般不会有数据的丢失。在备份时，db目录已经被Vob_snapshot备份，这个目录可以不用备份。
• 备份快照后的数据，当使用快照备份的Vob database与此服务器上的Vob在同一个物理设备时，该操作尤其重要。如果Vob物理设备损坏，而使用快照备份的数据没有备份到其他物理设备时，还是无法恢复Vob。

2.3.1 延期删除

当使用Vob_snapshot_setup时，就对该Vob启用了延期删除。当storage pool的备份在Vob_snapshot完成后的30分钟内进行，则会完整备份snapshot时的所有数据存储池的信息。默认情况下，按照元素的存储机制，一个元素的所有版本信息可存储在一个或多个物理文件中，当数据信息被更新时，新的存储文件被创建，旧的则被删除。如果延期删除启用后，旧的存储文件会被记录并保存30分钟。

延期删除需要更多的磁盘空间，在linux或unix平台上，可以使用kill -HUP pid （pid为Vob_server的pid）发送延续删除信息至Vob log中，可使用cleartool getlog Vob查看。

使用checkVob检查存储池时可以列出延期删除的文件列表。

延期删除列表每五分钟写入VOB存储目录中的delete_list.db中。

2.4 常规备份

    除了snapshot备份方式以外，还有另一种常规备份方式，可以按照下面的步骤来做：

A. 锁定Vob，不使用nusers参数；

B. 备份整个Vob存储目录，包括所有的远程storage pool；

C. 解除Vob的锁定

2.4.1 查看Vob的存储目录 

可以适用clearcase 管理控制台和cleartool lsVob来查看Vob的存储目录。如果备份程序在本地运行，则使用VOB server access path来定位Vob的存储目录，如果备份程序在网络中的其他计算机中运行，则应使用网络全局路径。

2.4.2 VOB的锁定和解锁 

必须用Vob的owner或clearcase特权用户的身份来进行Vob的锁定和解锁。有图形界面操作，也可使用cleartool lock和unlock命令方式。

2.4.3 远程存储池 

如果linux或unix的VOB server上存在远程存储池，则必须进行备份。无论是采用snapshot还是常规的备份方式。 在任意的View中执行lspool检查Vob是否存在远程存储池,可以用-long参数列出
cleartool lspool -long -inVob Vob:/Vob/src
pool "ampool"
2006-11-01T15:38:18+08 by root.root@ams
"among create Vob pool"
owner: root
group: root
kind: source pool
pool storage link target pathname "/home/among/ampool"
pool storage global pathname "/home/ccstg/Vobs/src.vbs/s/ampool"
pool "cdft"
2006-07-13T09:59:46+08 by root.root@ams
"Predefined pool used to store cleartext versions."
owner: root
group: root
kind: cleartext pool
pool storage global pathname "/home/ccstg/Vobs/src.vbs/c/cdft"
maximum size: 0 reclaim size: 0 age: 96 

注意：在unix和linux上，一些备份工具，如tar和cpio，用参数可以跟踪符号链接，如果远程存储池在备份期间可用，会备份符号链接及其实际文件内容。

2.4.4 如果不能备份全部数据时的可选备份 

如果使用文件级别的备份工具，则可以排除一些子目录以减少备份时间。在整个vbs目录中，第一层目录，db，s目录都一定需要备份的。admin和c目录可选，d目录里面存储着derived object，很重要，但不是必须的。VOB目录的重要性可以参见下表：

2.4.4.1 DO 存储池的备份 

ClearCase LT不支持构建管理，所有LT Vob中的DO存储池是空的，不需要备份，在动态View中使用clearmake，omake，clearaudit后，Derived object 存储池会存储相关信息。DO可以从源码重新编译，所以备份DO pool不是必须的，在不同情况，是否备份DO pool的重要性依不同情况而不同：

A. 在项目开发的早期，源程序变动频繁，大多数DO的使用机会很少，所以不备份DO pool不会有大的问题。

B. 当项目源程序趋于稳定时，会有很多DO的重用，DO的丢失会显著增加下次系统重构建的时间。

C. 已结束的项目中会包含许多很难重新构建的DO（如需要特殊的编译器，没有可用的View等），这些DO是有价值的，应该进行备份，更好的方式是作为元素进行版本控制。 

如不需要备份DO pool，至少需要备份pool的根目录（默认为d目录中的ddft）和 pool_id 文件。这样可防止恢复后checkVob时的检查错误。

2.4.4.2 Cleartext存储池的备份 

cleartext pool不是非常重要，它们可被重新创建，即使不备份cleartext pool，至少应该保存pool根目录（默认为c/cdft）和pool_id 文件，这样可防止恢复后checkVob时的检查失败。

2.4.4.3 Administrative目录的备份 

VOB中的admin目录保存着Vob及其存储池的空间占用情况统计信息。clearcase任务计划会定期收集磁盘空间信息并保存在该目录中。默认情况下会保存最近30天的数据，该数据不能被重建，如果觉得此数据很重要，注意备份admin目录。

2.4.5 不要执行增量备份 

当创建一个元素的新版本时，clearcase并没有修改已存在的物理数据文件，而是在数据存储池中创建一个不同名的新的物理数据文件，并把旧数据删除。该机制与大多数增量备份策略有冲突，增量备份只会备份上次备份以后修改和新增的文件。按照增量备份的机制来恢复，会恢复一些已被正常删除的文件，这些信息已经无用了。 

举例，当一个文本类的元素每天产生一个新版本，每天的增量备份会备份一个不同的物理存储文件，如果在这一周后进行恢复，会为该元素恢复所有的存储文件，而只有最后一个有用。checkVob会报告出这些无引用的数据。 所以增量备份对Vob的备份不太合适，应尽量避免，如使用，应保证完整备份后的增量备份次数尽量少。

2.5 视图（View）的备份

View中的数据与Vob不同，它们可被简单的重建，除了已经被check out的版本及私有文件，可以通过重建View来重现View中的数据。备份View也是重要的，尤其对那些没有定期check-in习惯的人。备份View与备份Vob类似，而且更简单一些。

View的目录结构中，View的storage directory存储在View server中，动态View中仅有一个私有的数据存储区.s目录，静态veiw中没有.s目录，所有的版本信息都在本地的View root directory中。

不要对View storage directory和View root directory进行部分的备份。所有的数据都是重要的。尤其是那些已经修改的check out后的文件及私有文件。

注意：备份View storage directory的工具必须可以备份那些为写入而打开的文件，如果工具不支持，则必须停止View server上的clearcase服务。

静态View和web View除了用View storage directory外，还有View root directory，用于存储下载下来的通过View config_spec过滤的版本信息。该目录也必须备份。

备份视图：

A. 列出View storage directory

可使用clearcase管理控制台或lsView命令列出View storage directory信息。如果通过网络备份，则需要网络的全局路径。请获取View server access path：
cleartool lsView –long r5_integration
Tag: r5_integration Global
path: /net/mars/Viewstg/r5_integration.vws
...
...
View on host: mars View server access path: /Viewstg/r5_integration.vws ...

B. 确保备份的完整与一致性

为确保View在备份过程中处于非活动状态，使用chView阻止用户更新View database
cleartool chView -readonly r5_integration
properties：readonly

该命令并不会阻止config_spec的修改，为保证备份的完整性，最好使用cleartool endView -server Viewtag停止View server上的View 服务。

C. 列出是否有远程存储池

在linux和unix上，使用ls命令列出View storage dierctory中是否存在软链接
ls –ld .s ... .s -> /net/ccsvr04/Viewstore/r5_integration.stg

该例中标识了一个远程的私有存储区，确保也可正常备份。

D. 进行备份

对于动态和静态View，备份整个View storage directroy，使用local path或网络全局path，对于静态View和web View，还需备份View root dierctory。

note：在备份和恢复静态View时，必须使用可以保存文件修改时间及权限的工具备份View内的文件，否则View内的文件会变为hijacked状态。

E. 后继操作

cleartool chView -readwrite r5_integration
Properties: readwrite

恢复View至可写的状态。

F. 如果将View存储目录改过名称，现在将名称再改回初始名称

2.6 备份Registry信息

ClearCase注册信息保存在注册服务器中的rgy目录下的一组文件中，它们都是普通的文件，可以进行常规的备份。请使用可备份已打开文件的备份工具。

• 在linux或unix上，注册信息位于/var/adm/rational/clearcase/rgy
• 在windows上，注册信息位于ccase-home-dir\var\rgy

所有的注册信息必须同时备份与恢复，已连接的客户端列表文件也需备份，它不在rgy目录中。

• 在linux或unix上，位于/var/adm/rational/clearcase/client_list.db
• 在windows上，位于ccase-home-dir\var\client_list.db

2.7 备份其他有关联的数据

在使用UCM的情况下，各种数据存储库之间存在着复杂的关系，可分为以下几种：

• UCM PVOB与Component VOB间有着hyperlink联系
• Administrative VOB多层次关系中metadata数据依靠hyperlink关联
• 在使用ClearQuest集成的UCM环境中，ClearCase PVOB与ClearQuest DB中相互关联，各自存储着关联的数据信息

UCM中的操作，如加入project，创建一个活动，deliver或是rebase会改变相关联的数据。在一些情况下，关联是相互的， 即使没有使用UCM，在Admin VOB的层次中一个小小的操作也会对多个VOB产生影响。在第一个和最后一个部分备份的间隔可能会很长。这样在恢复后，可能会出现数据不一致的情况。

对上图所示的环境中，按照下面的步骤做是一个好的备份策略：
   A. lock所有相关的VOB与ClearQuest Database
   B. 备份所有相关的VOB和ClearQuest Database
   C. unlock所有相关的VOB和ClearQuest Database

除了那些不大的Vob和较小clearquest db的情况下，不太可能在一个确切的时间内按照上面的步骤来备份所有的数据。即使可以一次备份所有的数据，也不太可能同时进行数据的恢复。更多的情况下是 一个或两个数据库恢复到原来的环境中，所以在恢复的数据库和原有数据库之间又会有数据不一致的情况发生。关于数据恢复后的修复关联请查看第十一章的内容。

一个常用的备份策略：
   A. 备份Component VOB，如可能，使用Vob_snapshot进行备份
   B. 备份关联的ClearQuest Database
   C. 使用Vob_snapshot备份PVOB，没有包含component信息的PVOB可用Vob_snapshot备份且不会有数据丢失。如果环境 中存在着多个PVOB，一起备份所有的PVOB和administrative VOB。(注意先锁定所有的Vob，备份，最后解锁。) 该策略能够最大化减少恢复后的数据不一致，在恢复后，PVOB比所有的ClearQuest Database和Component VOB都要新，会简化修复数据不一致的工作。

注意：在使用该备份策略时，尽量在一个最小的时间段内备份所有的数据。注意经常备份，在恢复时，一个昨天备份会比一周前备份的数据所产生的数据不一致要少。

查看数据关联

在非UCM环境中，数据库间的关联主要是administrator VOB层次，该层次是依靠hyperlink关联的，可使用clearcase管理控制台或cleartool desribe来查看AdminVOB的信息。一个VOB只可有一个AdminVOB的hyperlink指向上层，可接受多个VOB的AdminVOB hyperlink的指向。

在UCM环境中，所有的数据关联由project组织管理，在project中的所有可修改的Component，PVOB，关联的ClearQuest Database是相互关联的，必须被同时备份。（project中只读的Component也应备份，但只读的Component在PVOB中的引用数 据在较长的时间内不会被修改，所以可不参与上面的备份计划与其它数据一起备份。）可使用Project Explorer或cleartool lsproject来查看project中的component信息。

2.8 结束语

本文主要是以<<ClearCase Administrator’s Guide>>为依据和引用，对ClearCase的数据备份进行了描述，如果有其中有错误理解，还需读者及时指正。另外如果有读者对ClearCase的恢复感兴趣的话，也可以参见<<ClearCase Administrator’s Guide>>的第11章ClearCase的数据。