Select Page

I’m moving into a new office; thus, finding it a good time to refresh the P4 server.  After reading up more on the process, I found that I have an OS upgrade, a P4 upgrade, and a physical move upgrade.  It’s seeming more and more like starting fresh is the most balanced option, even if it means losing history.

Even though I’m starting anew, I still researched the backup and recovery process again.  I had initially researched a couple years ago when first Installing Perforce.

My initial information may have been a bit incorrect about being able to restore either from the database (journal/server) and versioned files (storage).  I came across some new Perforce documentation for the new Helix branding.  Perforce still suggests splitting the versioned files from the database.  But they also state two more things that I, apparently, neglected in my original article:

  • Place the journal file elsewhere than $P4ROOT.  Same rationale as for the versioned files.  Although, this is starting to feel a bit extreme for my application of the software.  Details can be found at the P4 Knowledge Base.
  • Perforce recommends creating checkpoint files during a regular backup routine.  It takes a snapshot of the journal while locking the database.  Again, unnecessary for my particular case.

To elaborate a bit further, there is an SO question about how to proceed with backup and recovery too that more succinctly states the process.

On top of all this, I typically synch down the latest files on one or two client machines.  If my office was vandalized, I could very likely re-add all files again – similar to what I’m doing this time around.