Slide 1
Most trusted JOB oriented professional program
DevOps Certified Professional (DCP)

Take your first step into the world of DevOps with this course, which will help you to learn about the methodologies and tools used to develop, deploy, and operate high-quality software.

Slide 2
DevOps to DevSecOps – Learn the evolution
DevSecOps Certified Professional (DSOCP)

Learn to automate security into a fast-paced DevOps environment using various open-source tools and scripts.

Slide 2
Get certified in the new tech skill to rule the industry
Site Reliability Engineering (SRE) Certified Professional

A method of measuring and achieving reliability through engineering and operations work – developed by Google to manage services.

Slide 2
Master the art of DevOps
Master in DevOps Engineering (MDE)

Get enrolled for the most advanced and only course in the WORLD which can make you an expert and proficient Architect in DevOps, DevSecOps and Site Reliability Engineering (SRE) principles together.

Slide 2
Gain expertise and certified yourself
Azure DevOps Solutions Expert

Learn about the DevOps services available on Azure and how you can use them to make your workflow more efficient.

Slide 3
Learn and get certified
AWS Certified DevOps Professional

Learn about the DevOps services offered by AWS and how you can use them to make your workflow more efficient.

previous arrow
next arrow

Recovery Procedures in Perforce

Spread the Knowledge

rajeshkumar created the topic: Recovery Procedures in Perforce
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 methodology

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
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: Re: Recovery Procedures in Perforce
Reference can be found in following link…
community.scmgalaxy.com/pg/blog/rajeshku…s-in-perforce-server
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Rajesh Kumar