Perforce 2007.2 System Administrator's Guide

Chapter 2: Supporting Perforce: Backup and Recovery• The current journal file, which should be on a separate filesystem from your P4ROOTdirectory, and which should therefore have been unaffected by any damage to thefilesystem where your P4ROOT directory was heldYou will not need:• Your backup of your versioned files; if they weren’t affected by the crash, they’realready up to dateTo recover the database1. Stop the current instance of p4d:p4 admin stop(You must be a Perforce superuser to use p4 admin.)2. Rename (or move) the database (db.*) files:mv your_root_dir/db.* /tmpThere can be no db.* files in the $P4ROOT directory when you start recovery from acheckpoint. Although the old db.* files are never used during recovery, it’s goodpractice not to delete them until you’re certain your restoration was successful.3. Invoke p4d with the -jr (journal-restore) flag, specifying your most recentcheckpoint and current journal. If you explicitly specify the server root ($P4ROOT), the-r $P4ROOT argument must precede the -jr flag:p4d -r $P4ROOT -jr checkpoint_file journal_fileThis recovers the database as it existed when the last checkpoint was taken, and thenapplies the changes recorded in the journal file since the checkpoint was taken.NoteIf you’re using the -z (compress) option to compress your checkpointsupon creation, you’ll have to restore the uncompressed journal fileseparately from the compressed checkpoint.That is, instead of using:p4d -r $P4ROOT -jr checkpoint_file journal_fileyou’ll use two commands:p4d -r $P4ROOT -z -jr checkpoint_file.gzp4d -r $P4ROOT -jr journal_fileYou must explicitly specify the .gz extension yourself when using the -zflag, and ensure that the -r $P4ROOT argument precedes the -jr flag.Check your systemYour restoration is complete. See “Ensuring system integrity after any restoration” onpage 37 to make sure your restoration was successful.34 Perforce 2007.2 System Administrator’s Guide