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 master's P4ROOT directory and plays back numbered journal files automatically. Versioned files (other than shelved files) edited after the checkpoint will be automatically pulled from the master. Assuming a checkpoint taken on the master is available, and replication configurables are set, no further downtime is needed on the master.

Stop the replica
```
p4 -p replica:1666 admin stop
```
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.
Copy the checkpoint file to the replica and replay it by running
```
p4d -r P4ROOT -jr checkpoint.312
```
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.
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 -l -j
```
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 master are on the replica.

Restore from checkpoint and journals copied from the upstream server

Stop the replica.
```
p4 -p replica:1666 admin stop
```
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).
Copy the checkpoint file to the replica and replay it.
```
p4d -r P4ROOT -jr checkpoint.312
```
Copy all numbered journals created subsequent to the checkpoint (if any) from the master 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.
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
```
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 master are on the replica.