Checkpoints are not created automatically; someone or something must run the checkpoint command on the Perforce server machine. To create a checkpoint, invoke the p4d program with the -jc (journal-create) flag:

$ p4d -r server_root -jc

You can create a checkpoint while the Perforce service (p4d) is running. The checkpoint is created in your server root directory (that is, P4ROOT if no server_root is specified).

To make the checkpoint, p4d locks the database and then dumps its contents to a file named checkpoint.n in the P4ROOT directory, where n is a sequence number.

Before unlocking the database, p4d also copies (on UNIX where the journal is uncompressed, renames) the journal file to a file named journal.n-1 in the P4ROOT directory (regardless of the directory in which the current journal is stored), and then truncates the current journal. The MD5 checksum of the checkpoint is written to a separate file, checkpoint.n.md5, and the lastCheckpointAction counter is updated to reflect successful completion.

This guarantees that the last checkpoint (checkpoint.n) combined with the current journal (journal) always reflects the full contents of the database at the time the checkpoint was created.

The sequence numbers reflect the roll-forward nature of the journal. To restore databases to older checkpoints, match the sequence numbers. That is, you can restore the state of the Perforce server as it was when checkpoint.6 was taken by restoring checkpoint.5 and then loading journal.5 which contains all the changes made between checkpoint.5 and checkpoint.6. In most cases, you’re only interested in restoring the current database, which is reflected by the highest-numbered checkpoint.n rolled forward with the changes in the current journal.

To specify a prefix or directory location for the checkpoint and journal, use the -jc option. For example, you might create a checkpoint with:

$ p4d -jc prefix

In this case, your checkpoint and journal files are named prefix.ckp.n and prefix.jnl.n respectively, where prefix is as specified on the command line and n is a sequence number. If no prefix is specified, the default filenames checkpoint.n and journal.n are used. You can store checkpoints and journals in the directory of your choice by specifying the directory as part of the prefix. For example

$ p4 -r . -J /where/my/journal/lives/journal -z -jc
                /Users/bruges/server151/checkpoints/mybackup

returns

Checkpointing to /Users/bruges/server151/checkpoints/mybackup.ckp.299.gz…
MD5 (/Users/bruges/server151/checkpoints/mybackup.ckp.299) = 5D7D8E548D080B16ECB66AD6CE0F2E5D
Rotating journal to /Users/bruges/server151/checkpoints/mybackup.jnl.298.gz…

You can also specify the prefix for a server with:

$ p4 configure set journalPrefix=prefix

When the journalPrefix configurable is set, the configured prefix takes precedence over the default filenames. This behavior is particularly useful in multi-server and replicated environments.

To create a checkpoint without being logged in to the machine running the Perforce service, use the command:

$ p4 admin checkpoint [-z | -Z] [prefix]

Running p4 admin checkpoint is equivalent to p4d -jc except that using p4 admin checkpoint requires that you be connected to the server. You must be a Perforce superuser to use p4 admin.

You can set up an automated program to create your checkpoints on a regular schedule. Be sure to always check the program’s output to ensure that checkpoint creation was started. Compare the checkpoint’s actual MD5 checksum with that recorded in the .md5 file, and back up the .md5 file along with the checkpoint. After successful creation, a checkpoint file can be compressed, archived, or moved onto another disk. At that time or shortly thereafter, back up the versioned files stored in the depot subdirectories.

To restore from a backup, the checkpoint must be at least as old as the files in the depots, that is, the versioned files can be newer than the checkpoint, but not the other way around. As you might expect, the shorter this time gap, the better.

If the checkpoint command itself fails, contact Perforce technical support immediately. Checkpoint failure is usually a symptom of a resource problem (disk space, permissions, and so on) that can put your database at risk if not handled correctly.

You can use the p4 journals command to display the history of checkpoint and journal activity for the server. This history includes information about the following events: the server takes a checkpoint, journal rotation, journal replay, checkpoint scheduling. For detailed information about command output and options, see the description of the p4 journals command in the P4 Command Reference.

You can verify the integrity of a checkpoint using the p4d -jv command.

To configure Perforce to run trigger scripts when journals are rotated, use the journal-rotate and journal-rotate-lock type triggers. Journal-rotate triggers are executed after the journal is rotated on a running server, but only if journals are rotated with the p4 admin journal or p4 admin checkpoint commands. Journals are not rotated if you invoke the p4d -jc or p4d --jj commands.

Journal-rotate triggers allow you to run maintenance routines on servers after the journal has been rotated, either while the database tables are still locked or after the locks have been released. These triggers are intended to be used on replicas or edge servers where journal rotation is triggered by journal records. The server must be running for these triggers to be invoked.

See Triggering on journal rotation for more information.

To disable journaling, stop the service, remove the existing journal file (if it exists), set the environment variable P4JOURNAL to off, and restart p4d without the -J flag.

Versioned files are stored in subdirectories beneath your server root. Text files are stored in RCS format, with filenames of the form filename,v. There is generally one RCS-format (,v) file per text file. Binary files are stored in full in their own directories named filename,d. Depending on the Perforce file type selected by the user storing the file, there can be one or more archived binary files in each filename,d directory. If more than one file resides in a filename,d directory, each file in the directory refers to a different revision of the binary file, and is named 1.n, where n is the revision number.

Perforce also supports the AppleSingle file format for Macintosh. These files are stored in full and compressed, just like other binary files. They are stored in the Mac’s AppleSingle file format; if need be, the files can be copied directly from the server root, uncompressed, and used as-is on a Macintosh.

Because Perforce uses compression in the depot file tree, do not assume compressibility of the data when sizing backup media. Both text and binary files are either compressed by p4d (and are denoted by the .gz suffix) before storage, or they are stored uncompressed. At most installations, if any binary files in the depot subdirectories are being stored uncompressed, they were probably incompressible to begin with. (For example, many image, music, and video file formats are incompressible.)

In order to ensure that the versioned files reflect all the information in the database after a post-crash restoration, the db.* files must be restored from a checkpoint that is at least as old as (or older than) your versioned files. For this reason, create the checkpoint before backing up the versioned files in the depot directory or directories.

Although your versioned files can be newer than the data stored in your checkpoint, it is in your best interest to keep this difference to a minimum; in general, you’ll want your backup script to back up your versioned files immediately after successfully completing a checkpoint.

Your restoration is complete. See Ensuring system integrity after any restoration to make sure your restoration was successful.

The database recovered from your most recent checkpoint, after you’ve applied the accumulated changes stored in the current journal file, is up to date as of the time of failure.

After recovery, both your database and your versioned files should reflect all changes made up to the time of the crash, and no data should have been lost. If restoration was successful, the lastCheckpointAction counter will indicate "checkpoint completed".

Your restoration is complete. See Ensuring system integrity after any restoration to make sure your restoration was successful.

Files submitted to the depot between the time of the last system backup and the disk crash will not be present in the restored depot.

$ p4 diff -se

After recovery, your depot directories might not contain the newest versioned files. That is, files submitted after the last system backup but before the disk crash might have been lost.

In either case, contact Perforce Technical Support for further assistance.