Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Replica server metadata recovery

This is the procedure for restoring (also called reseeding) a replica server when you detect an inconsistency or corruption in the replica database.

Although the procedures described below cause depot files to be brought up to date, they are not recommended for the initial population of depot files for a new replica. For that purpose, it is more efficient to use scp or rsync for Linux or xcopy for Windows.

## Restore from a specified checkpoint

This method looks in the P4ROOT directory of the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. and plays back numbered journal files automatically. Versioned files (other than shelved files) edited after the checkpoint will be automatically pulled from the target server. Assuming a checkpoint taken on the target server is available, and replication configurables are set, no further downtime is needed on the target server.

1. Stop the replica

       p4 -p replica:1666 admin stop

2. Move the replica's database and associated metadata files to a safe place. The files are named db.* in the replica's P4ROOT directory such as db.rev and db.protect. Move any journal and log file, as well as any `.lbr` file and any `state` file, including `statejcopy` if it exists.

3. Copy the checkpoint file to the replica and replay it by running

       p4d -r P4ROOT -jr checkpoint.312

4. Ensure that any numbered journals created subsequent to the checkpoint having been taken on the upstream server are in the upstream server's designated directory and that numbered journals have not been compressed. Replication cannot use compressed journal files. For example, if `journal.312` exists, it must be uncompressed.

5. Start the replica.

6. Check that replication is running. You should observe the journal and sequence numbers increasing when you run this command against the replica:

       p4 -p replica:1666 pull -l -j

7. Schedule the transfer of missing revisions.

   This is especially needed If the checkpoint used to seed the replica is newer than the archive files on the replica.

   Update the replica with the missing revisions for archive and shelved files using the commands:

       p4 -p replica:1666 verify -qt //...

       p4 -p replica:1666 verify -qtS //...

   Alternatively, use a command like rsync to make sure the versioned files on the target server are on the replica.

## Restore from checkpoint and journals copied from the upstream server

1. Stop the replica.

       p4 -p replica:1666 admin stop

2. Move the replica's database and associated metadata files to a safe place. The files are named db.* in the replica's P4ROOT directory such as db.rev and db.protect. Move any journal and log file, and any .lbr file and any state file (including 'statejcopy' if it exists).

3. Copy the checkpoint file to the replica and replay it.

       p4d -r P4ROOT -jr checkpoint.312

4. Copy all numbered journals created subsequent to the checkpoint (if any) from the target server to the replica and replay these on the replica.

       p4d -r P4ROOT -jr journal.312

       p4d -r P4ROOT -jr journal.313

   Note the running journal (usually named "journal") has not been restored.

5. Start the replica.

   Check that replication is running. You should observe the journal and sequence numbers increasing when you run this command against the replica:

       p4 -p replica:1666 pull -lj

6. Schedule the transfer of missing revisions.

   This is especially needed If the checkpoint used to seed the replica is newer than the archive files on the replica.

   Update the replica with the missing revisions for archive and shelved files using the commands:

       p4 -p replica:1666 verify -qt //...

       p4 -p replica:1666 verify -qtS //...

   Alternatively, use a command like rsync to make sure the versioned files on the target server are on the replica.

Your search for returned results