说到备份，我开始是用复制文件的方式，完全复制到本地，这样的好处是简单易操作，恢复的时候直接把备份拷回服务器，覆盖原来的数据即可，但是有数据量大的缺点。现在采用的是生成.ssa的备份文件，这样能节省很多空间。如果你也是生成.ssa格式的备份方法，恢复是要注意：

　　1.若原来作的是archive all the date的备份，并且没有将原project删除。

　　则："删除"原来的project再作恢复。

　　2.若原来作的 archive this version and older且你确认要回复到原来的版本

　　则："删除"原来的project再作恢复。（此时如果projects中有与其它projects共享的文档，新的版本不被覆盖）

　　注：

　　1.第2种方法备份方法（archive this version and older）不推荐，除非你想省硬盘空间，那么请在备份后将原来的版本删除这个选项打上，

　　以免恢复时麻烦。

　　2."删除"一个project可以在vss explore中进行，也可以在vss administrator中进行。

　　其实，CM说白了还是进行版本管控，至于怎么管控，个人的方法会不同，但是目的都是一样。一般公司可能会用两天服务器，一台做项目人员开发库，另一台做受控库和基线库。采用这种方法，要求配置管理员每次从项目开发库取出来数据，自己的工作台起到中介作用，这种情况下，可以在自己工作台上建立和库一样的目录，可以直接Get from 项目人员开发库和受控库到本地，以后需要更新的内容直接Check out到本地然后在Check in

　　进受控库。我们是受控库，基线库和项目人员开发库在一台服务器上，但是操作类似。我认为有条件还是把受控库和项目人员开发库分开，出于安全考虑，放两台服务器上更好管理，这样权限管理变的更简单。

　　看到一篇资料上介绍如何建立一个相对"安全"的VSS数据保护体系，自己整理了一下，供大家参考。

　　1.设一个安全文件夹与数据库目录平行（比如库在d:docvssaaa，则该目录设置为d:docvsslock），将此目录设为隐藏，普通组员的权限设为可读

　　写但不能列目录。不能通过浏览器直接访问该目录，以防误删除。

　　2.VSS库所在的目录共享不变，但只保留srcsafe.ini文件，其它的一切移入上述的安全文件夹中。(创建d:docvsslockaaa，容纳原aaa中文件及子文件夹)

　　3.在文件srcsafe.ini中，将路径和文件指向实际的内容（加相对路径，比如原来是Data_Path = data， 现在改为..lockaaadata，其它类推）。

　　srcsafe.ini改好后作一个备份，用以损坏后恢复。

　　4.在上述安全目录中加入一随机取文件名如（asdhfn3.7d），对该文件的读取和写入进行系统的监控（观察是否有非法访问）

　　5.这个安全体系并没有排除硬件的故障以及他人用administrator的权限进行破坏的情况，所以定期备份还是需要的。

　　归纳一下，现在已经完成和正在完成的文档有：

　　1）配置状态报告

　　2）日常备份申请

　　3）配置管理计划

　　4）配置管理周报

　　5）配置库系统

　　6）配置项状态表

　　有了这些表的规范，我相信后面的配置管理应该会更明确了。

　　现在需求阶段的基线已经发布，并通过了评审，进入概要设计和详细设计阶段，在项目中成长吧，进步是看的见的。