1.2 配置库的备份
完成配置库的创建后，我们就需要定义适当的配置库备份过程。配置管理系统的备份包括VOB、视图、注册信息等，这里我们主要说明如何对VOB进行备份。
对于VOB的备份，我们需要根据VOB服务器操作系统的不同来调整相应的备份流程。
·如果VOB服务器的操作系统是UNIX/Linux，那么备份过程就是在备份前lock所有VOB，然后备份VOB Storage，完成备份后，unlock所有VOB。
·如果VOB服务器的操作系统是Windows，那么在备份VOB Storage目录之前，需要先停止ClearCase服务，完成VOB Storage备份后，启动ClearCase服务后再unlock所有VOB。在Windows上，即使为了备份已经lock了VOB，但是vob_server进程仍会让VOB数据库文件处于打开状态。许多Windows备份工具都不具备能够备份处于打开状态的文件的功能。它们会跳过处于打开状态的文件，这使得备份工作毫无价值。所以，对于Windows操作系统，我们在备份VOB时，需要将ClearCase服务进程停止，保证所有VOB数据库文件没有处于打开状态。
我们为了备份而中止ClearCase服务进程，意味着在这段时间内，ClearCase调度程序将无法运行，因此不会有任何按计划被调度的进程执行，比如每日的Scrubber进程或MultiSite的Export等复制进程等。因此我们应该合理安排备份时间与ClearCase后台调度例程之间的先后次序。在实际操作中，我们可以根据VOB备份所需的时间来定义其他调度进程执行时间。假设VOB备份需要3个多小时，那么我们可以设置从零点开始执行VOB备份进程，其他后台调度进程就设置在4点之后进行，错开各个调度进程之间的执行时间。
2 控制和审计工件的变更
工件经过标识并存入配置库之后，需要控制什么人获准修改这些工件，还要保持修改的相关信息：什么人做的修改，什么时候做的修改，为什么要做修改。我们称这些修改的相关信息为“审计信息”。这项实践对应于CMMI过程的“配置控制”、“配置状态统计”。如果没有进行控制，那么任何人都可以对系统做修改，这对于项目工件的安全与正确性是个严重的隐患。对于工件的控制，我们可以通过权限、UCM流程来实现。至于什么人做的修改，什么时候做的修改，这可以通过ClearCase本身的版本记录信息来实现。为什么要做修改，则可通过开发人员填写的检入注释，或者是修改文件时关联的活动描述来记录。
我们通过下面的章节具体说明如何在项目中使用ClearCase来实现控制和审计工件的变更。
2.1 权限与安全
ClearCase通过以下四种类别的权限来进行安全控制：操作系统权限、VOB/View权限、目录权限和文件权限，这四种权限是逐层嵌套的。在你能访问一个ClearCase元素时，这里有几层的安全机制必须考虑到：
·设置正确的VOB Storage权限，以便你能够访问ClearCase存储池。
·你使用的视图是否有权限访问VOB？为了能够访问VOB，你所属的组是否在VOB的组列表中？
·一旦你可以访问VOB，你是否有权限可以访问目录？
·如果你可以访问一个目录，你是否有权限可以访问目录里的元素？
·是否有ClearCase触发器限制你访问元素？
ClearCase使用用户、用户组来进行权限控制的，包括User（属主）、Group（属组）、Other三个类别，每个类别的权限包括读、写、执行三种。在图三的例子中，doc目录的属主是XFSHEN\judy，这个用户具有读、写、执行三种权限；属组是XFSHEN\None，它具有读和执行权限；Other组则没有任何权限。
