Recovery Procedures in Perforce Server
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
MotoShare.in delivers cost-effective bike rental solutions, empowering users to save on transportation while enjoying reliable two-wheelers. Ideal for city commutes, sightseeing, or adventure rides.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals
