[SCM]源码管理 - perforce的备份恢复和升级

 

一 p4server上文件类型

0) p4server的文件组成：

 

1）文件类型如下图：

2）depot目录及目录下的所有文件为developer真正提交的代码文件信息，我们成为versioned files ；

（depot下文件为rcs格式，参考：http://durak.org/sean/pubs/software/cvsbook/RCS-Format.html）

例如如下changlist：

在depot下对应的文件为：versiontest.txt,v

head      1.75 ;
access    ;
symbols   ;
locks     ; comment  @@ ;

1.75
date       2010.06 . 21.22 . 56.05 ;   author p4 ;   state Exp ;
branches  ;
next      1.74 ;

1.74
date       2010.06 . 21.22 . 55.30 ;   author p4 ;   state Exp ;
branches  ;
next      ;

desc
@@

1.75
log
@@
text
@ 111

222 @

1.74
log
@@
text
@d1  3
a3  1
111 @

 

3）db.*文件为p4 server的database文件，每一个db.*相当于一个database的一个table。很多的地方也称为metadata。存储了所有的除源代码以外的p4 server的信息，例如users，groups，depots，changes，labels，jobs。。。

4）checkpoint+journal文件，是p4 server的database的备份文件。checkpoint是对某一时刻所有的db.*文件的一个镜像。journal是从某个checkpoint以后所有对p4 server的操作记录。

 

例如当你某时创建checkpoint的时候，会生成 checkpoint.5 和 journal.4。 其实checkpoint.5的内容就是等于checkpoint.4内容加上journal.4的内容，journal.4中包含了checkpoint.4到checkpoint.5之间的所有的操作。 在最新的checkpoint后的操作被记录在了journal文件中。 

 

 

二 备份和恢复的文件

1）p4 server备份需要同时备份versioned files 和 checkpoint + journal。

2）p4 server备份和恢复的过程，如下：

  

三 备份

1）验证server的完整性，对上次备份后有修改的文件增加MD5信息和文件的长度信息到p4的db中: 

p4 verify //... 或 p4 verify -qz //...

通过在备份前运行p4 verify， 可以确保对于上次备份后修改的文件的MD5和文件长度信息也被记录到p4的db中。 p4 verify不仅可以在备份前识别出server的问题，而且还可以用来验证恢复是否正确。

2)创建checkpoint，使用命令p4d 且带参数 -jc (journal-create) ，此步骤其实包含了创建checkpoint，然后保存journal为old journal，然后创建新的journal文件来记录将来的修改: 
p4d -jc

或者也可以使用p4 admin 命令，p4 admin需要设置环境变量p4port，p4user，也可以在远程的机器上执行：

p4 admin checkpoint

 

3) 在备份任何文件前请确保checkpoint被成功地创建。可以通过查看p4d -jc的返回值来判断checkpoint是否创建成功，或者也可以检查对应的journal是否被创建。

4) 一旦checkpoint被成功地创建，就可以备份checkpoint文件，老的journal文件，和versioned files。

 

当创建checkpoint的时候，perforce database将被lock。所以最好的办法是第一次备份时手动创建离线的database， 以后备份时，先将最新的journal应用到离线的database，然后再对离线的database备份即可 。

在2010.2以后的版本中，可以建立replicated server，专门用来创建备份。

默认地checkpoint和journal被创建在p4root设置的目录中，但是可以p4d -jc prefix 来将checkpoint和journal创建到新的目录，在使用了prefix参数后，checkpoint和journal的名字将变为prefix.ckp.n and prefix.jnl.n-1。

 

通常地我们使用p4journal 或对p4d [-jc]使用-J filename来将当前的journal生成到不同于p4root的地方。避免当p4root目录有问题时，从上次checkpoint后的修改也丢失。如果p4 server启动时使用了-J filename参数，则checkpoint时也必须使用使用-J filename来指定正确的journal文件。例如：
#启动server
$ p4d -r $P4ROOT -p 1666 -J /usr/local/perforce/journalfile
#创建checkpoint
$ p4d -r $P4ROOT -J /usr/local/perforce/journalfile -jc
Checkpointing to checkpoint.19...
Saving journal to journal.18...
Truncating /usr/local/perforce/journalfile...

 

四 恢复

1) 停止当前的p4server实例: 
p4 admin stop
(必须是p4 supperuser或admin才可以使用 p4 admin.)

2) 重命名或移除旧的db.*文件:
mv your_root_dir/db.* /tmp

将旧的db.*移动到某个备份目录是比较好的做法，在确保所有的恢复的正确后在删除旧的db.*文件。

3)  使用命令p4d 和参数-jr (journal-restore) 来恢复, 且需要指定最新的checkpoint和当前的journal文件。如果你需要指定serverroot，则-r $P4ROOT参数必须先于-jr:
p4d -r $P4ROOT -jr checkpoint_file journal_file

（或者简单地只恢复到最后的checkpoint：p4d -r $P4ROOT -jr checkpoint_file ）
如果只是简单的恢复到最后的checkpoint，则在checkpoint后的修改则没有被恢复。如果你在备份的时候使用了-Z参数来压缩checkpoint，则在恢复的时候需要单独的恢复journal，也就是说将原来的命令:
p4d -r $P4ROOT -jr checkpoint_file journal_file
分解为2个命令:
p4d -r $P4ROOT -z -jr checkpoint_file.gz
p4d -r $P4ROOT -jr journal_file
当使用-z参数的时候，必须显式地指定.gz后缀，且必须确保-r $P4ROOT 先于参数 -jr。

4) 在恢复完成后，使用p4 verify来验证，确保versioned files是新于database:
p4 verify -q //...
此命令验证了versioned files的完整新。-q参数表示只输出错误信息。正常地此命令没有任何输出。

 

五 最佳实践

1）对versioned files和checkpoint+journal 备份到不同的drive。

2）p4d 启动时使用-J来指定最新journal的位置，因为最新的journal在crash前还没有来得及备份。

 

六 P4server的升级

1）停止p4server；

2）创建checkpoint，且备份旧的p4d文件；

3）使用新的p4d替换旧的，在windows上也可以使用perforce.exe来重新安装新的p4d；

4）使用命令来升级database：p4d -r server_root -J journal_file -xu；

5）升级成功后重新启动p4server；

 

完！