Backup/Restore

Overview

There are three important components in the Perforce backup restore procedure:

The versioned files - these are the actual versioned files stored in the perforce depots in the system (see 'server.depot.root' configuration variable)
The perforce checkpoint file - this is generated as part of the backup procedure, it is a condensed record of all the meta-data transactions that have been performed prior to the time the checkpoint file was generated on the perforce server
The perforce journal file - this is a much less condensed record of all the meta-data transactions that have been performed on the perforce server since the last checkpoint file was generated.

Backup related Configuration variables:

> p4 configure show
...
journalPrefix=/usr/share/mdx/repos/backup/p4d_backup_myserver (configure)
server.depot.root=/usr/share/mdx/repos/p4/depots (configure)
...

The journalPrefix variable points to the location of the journal file.

The server.depot.root variable points to the location of the versioned files (which are stored under each depot in the location pointed to by server.depot.root).

Standard Backup Procedure

Journals and Checkpoints

Every transaction a Perforce server has is captured in a journal file. The server database can be recovered from this journal of transactions, however the journal file tends to grow very large over time. For this reason a perforce server should be checkpointed at some regular interval. A checkpoint is a snapshot of the state of the database at a given time. When a checkpoint is taken the journal is 'rotated' meaning the server stops writing to the old journal file and starts writing to a new journal file. After checkpointing the server can now be recovered from the latest checkpoint plus the latest journal file. The old journal file (and any old checkpoints) can be offloaded to another storage medium to free up disk space.

The Journal file location is configured with the following p4 configure setting:

> p4 configure set journalPrefix=myserver#/usr/share/mdx/repos/backup/p4d_backup_myserver

The Journal file should be placed on a different physical drive than the one that holds the perforce database files and the backed up checkpoint files to avoid a disk corruption affecting the backed up files and the live database.

Taking a Checkpoint

A checkpoint is taken in one of two ways

> p4d -jc
 
or
 
> p4 admin checkpoint

More information on the "p4 admin" command is here.

The database is locked during the checkpointing process so the server does not need to be stopped during this time.

The output of the checkpoint command should be checked for errors and the md5 checksum of the generated file should be verified against the .md5 file created by the checkpoint process.

After the checkpoint is taken the versioned files can be backed up via any convenient means, it is important to back up the versioned files AFTER the checkpoint so that all the changes to these files are captured in the checkpoint (it is alright if the files have more changes than captured by the checkpoint).

The old journal file can be backed up as well (though not strictly necessary for the recovery process it is a good idea to keep them). If the new checkpoint number is n, the journal file number will be n-1.

The checkpoint file should be moved to a backup location.

It is also necessary to back up the server.id file if the p4 serverid command has been used to id the server. This file exists in the P4ROOT directory.

For more information see the Helix Versioning Engine Administrators Guide: Fundamentals.

Restore Procedure

Restoration of the perforce database is accomplished from the latest checkpoint file plus the latest journal file (see 'Journals and Checkpoints' above). The exact sequence to follow depends on what problem has occurred, please see the Helix Versioning Engin Administrators Guide: Fundamentals for details on restoring the Perforce installation.

Backup/Restore of Replicated Servers

Checkpoints of Replica servers should be coordinated with the master server. For Replicas the 'p4d -jc' command should not be used (and is prevented in servers of version 2015.1 or higher), rather the 'p4admin checkpoint' command should be used.

Once 'p4admin checkpoint' has been run against the replica the replica will wait until it detects a checkpoint being taken on the master server, at which point it will take its own checkpoint.

Please see the Perforce Knowledge Base article 'Taking Checkpoints on Edge and Replica Servers' for more information.