If the database files become corrupted or lost, either because of disk errors, a hardware failure such as a disk crash, the database can be recreated with your stored checkpoint and journal. it can at least provide a general guideline for recovery from the two most common situations, specifically:

1. corruption of your Perforce database only, without damage to your versioned files, and
2. corruption to both your database and versioned files.

Case 1: Database corruption, versioned files unaffected

You will need:
1. The last checkpoint file, which should be available from the latest P4ROOT directory backup.

2. The current journal file, which should be on a separate filesystem from your P4ROOT directory, and which should therefore have been unaffected by any damage to the filesystem where your P4ROOT directory was held.

You will not need:
1. Your backup of your versioned files; if they weren’t affected by the crash, they’re already up to date.

To recover the database

1. 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.* /tmp

There can be no db.* files in the $P4ROOT directory when you start recovery from a checkpoint. Although the old db.* files are never used during recovery, it’s good practice not to delete them until you’re certain your restoration was successful.

3. Invoke p4d with the -jr (journal-restore) flag, specifying your most recent checkpoint 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_file

This recovers the database as it existed when the last checkpoint was taken, and then apply the changes recorded in the journal file since the checkpoint was taken.

Case 2: Both database and versioned files lost or damaged

You will need:
1. The last checkpoint file, which should be available from the latest P4ROOT directory backup.
2. Your versioned files, which should be available from the latest P4ROOT directory backup.

You will not need:

Your current journal file. The journal contains a record of changes to the metadata and versioned files that occurred between the last backup and the crash; because you’ll be restoring a set of versioned files from a backup taken before that crash, the checkpoint alone contains the metadata useful for the recovery, and the information in the journal is of limited or no use.

To recover the database

1. Stop the current instance of p4d:

p4 admin stop
(You must be a Perforce superuser to use p4 admin.)

2. Rename (or move) the corrupt database (“db.”) files:
mv your_root_dir/db.* /tmp

The corrupt db.* files aren’t actually used in the restoration process, but it’s safe practice not to delete them until you’re certain your restoration was successful.

3. Invoke p4d with the -jr (journal-restore) flag, specifying only your most recent checkpoint:

p4d -r $P4ROOT -jr checkpoint_file

Some Tips While Setting up Perforce Server Configuration to have best Backup & Recovery methodlogy

1. Make sure you are using Symbolic Links for storing versioned files in another drive
2. Make sure you are Storing Journal files in differnet directory
2. Make sure you are storing check points in different directory

The post Recovery Procedures in Perforce Server appeared first on scmGalaxy.