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

Stop the p4d server:
```
$ p4 admin stop
```
(You must be a Helix Server superuser to use p4 admin.)
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.
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 may need to decompress them and account for line ending differences.)
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.

Note

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 Helix 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 Helix Server believes them to have. After verifying that these files are indeed the files you want to restore, you may 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.