[p4] Backing up Perforce

[Robert Cowham]

> I'm quite confused about how my backup script should work with storing
> the checkpoint and journal files.   The following are the steps I am
> currently taking:
> 
> p4 verify //...

I'd make that "p4 verify -q //..." and look for any output (which indicates
an error) - then mail someone if so.

> p4 verify -u //...  ( this seems redundant to me, but that's 
> what i thought it said to do in the documentation)

This is redundant with servers from 2003.2 onwards - from release notes:

Minor new functionality in 2003.2

	#47719 * **
	    The MD5 digest (fingerprint) of files are now computed and
	    stored during submit.  For best performance, use both a new
	    2003.2 client as well as server, as the new 2003.2 client
	    programs offload the MD5 computation from the server.  (Bug
	    #2696).

> p4 admin checkpoint
> 
> I then backup the new checkpoint, the old journal, and the 
> depot directories.
> 
> When looking at how to restore the data, it says that all I 
> need is the saved checkpoint file.  If this is true, what's 
> the purpose of the journal file?

Checkpoint/journal numbering goes:

Checkpoint.ckp.1
Checkpoint.jnl.0

Then
Checkpoint.ckp.2
Checkpoint.jnl.1

The reasoning for the numbering is:

Checkpoint.ckp.2 = Checkpoint.ckp.1 + Checkpoint.jnl.1

Thus the archived journals provide:
- extra safety in the absence of latest checkpoint (unlikely occurrence I
think since you are likely to lose both or neither!)
- audit trail of activity since recent checkpoint

The audit trail can be very useful. Also, with larger sites where they don't
checkpoint nightly, but do truncate journals, the journals can be used to
keep a standby server up to date.

> As of right now, all data is backed up every weeknight, and 
> we dont have separate file systems for DB vs depot.  We only 
> have about a dozen or so users and our code base is fairly 
> small (<200mb).

Life is always easier when you can do everything nightly. Are your disks
RAID'ed? Even with a small site it is worth considering disaster recovery
scenarios and the risks of downtime.

HTH
Robert