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

P4 Server Administration Documentation | 2025.2

# Both database and versioned files lost or damaged

If both your database and your versioned files were corrupted, you need to restore both the database and your versioned files, and you’ll need to ensure that the versioned files are no older than the restored database.

You will need:

- The last checkpoint file, which should be available from the latest `P4ROOT` directory backup. If, when you backed up the checkpoint, you also backed up its corresponding `.md5` file, you can confirm that the checkpoint was restored correctly by comparing its checksum with the contents of the restored `.md5` file.
- 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 `p4d` server:

       p4 admin stop

   (You must be a P4 Server 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. Compare the MD5 checksum of your most recent checkpoint with the checksum generated at the time of its creation, as stored in its corresponding `.md5` file.

   The `.md5` file written at the time of checkpointing holds the checksum of the file as it existed before any compression was applied, and assumes UNIX-style line endings even if the service is hosted on Windows. If your checkpoint file was created with the `-z` compression option, you might need to decompress them and account for differences in line endings.

4. Invoke `p4d` with the `-jr` (journal-restore) flag, specifying only your most recent checkpoint:

       p4d -r $P4ROOT -jr checkpoint_file

   This recovers the database as it existed when the last checkpoint was taken, but does not apply any of the changes in the journal file. (The `-r $P4ROOT` argument must precede the `-jr` flag. Also, because the `p4d` process changes its working directory to the server root upon startup, any relative paths for the `checkpoint_file` must be specified relative to the `P4ROOT` directory.)

   The database recovery without the roll-forward of changes in the journal file brings the database up to date as of the time of your last backup. In this scenario, you do not want to apply the changes in the journal file, because the versioned files you restored reflect only the depot as it existed as of the last checkpoint.

## To recover your versioned files

After you recover the database, you need to restore the versioned files according to your operating system’s restoration procedures to ensure that they are as new as the database.

## Check your system

Your restoration is complete. See Ensure system integrity after a 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.

Although "new" files (submitted to the depot but not yet backed up) do not appear in the depot after restoration, it’s possible (indeed, highly probable!) that one or more of your users will have up-to-date copies of such files present in their client workspaces.

Your users can find such files by using the following P4 Server command to examine how files in their client workspaces differ from those in the depot. If they run this command:

    p4 diff -se

They are provided with a list of files in their workspace that differ from the files P4 Server believes them to have. After verifying that these files are indeed the files you want to restore, you might want to have one of your users open these files for `edit` and submit the files to the depot in a changelist.

## Your system state

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 most cases, the latest revisions of such files can be restored from the copies still residing in your users' client workspaces.
- In a case where only your versioned files (but not the database, which might have resided on a separate disk and been unaffected by the crash) were lost, you might also be able to make a separate copy of your database and apply your journal to it in order to examine recent changelists to track down which files were submitted between the last backup and the disk crash.

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

Your search for returned results