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

P4 Server Administration Documentation | 2025.1

# Edge server metadata recovery

If you have a valid checkpoint and journals for the edge server, use the procedure at Database corruption, versioned files unaffected instead of the procedure below.

If you are using the Server Deployment Package (SDP), use the procedure at Edge Reseed Scenario in the documentation of Perforce P4 Server Deployment Package (for UNIX/Linux).

## Prerequisites

The procedure below for edge server metadata recovery applies if all of the following are true:

- You are running the 2022.1 version or later of the P4 Server.
  Otherwise, use the 2021.2 version of edge server metadata recovery.

- One or more database tables are corrupt on the edge server, and no checkpoint is available to recover those database tables.

- None of the corrupted edge server tables belong to the List of filtered out tables at Create and start the edge servers.

- Archive files on the edge server are intact or have been restored from a backup. If restored from a backup, they might not be up to date with the recovered metadata.

## Steps for edge server metadata recovery

These steps assume familiarity with the P4 Server (p4d) reference for checkpoints and restoring. If you want guidance, contact Perforce Support.

1. Stop the edge server.

2. Move the database tables, `db.user.rp`, and the file called `state` from the edge server root directory to a safe directory.

3. Dump the local edge server tables and copy them to a safe directory.

   1. Copy the List of filtered out tables string for your server release from the Create and start the edge servers topic.

   2. Append that string with the suffix
      `,db.view,db.label,db.revsx,db.revux`
      For example, using lowercase `k` to select only the tables enclosed in the double-quoted string:

          p4d -r edgeroot -k
          "db.have,db.working,db.locks,db.resolve,db.revsh,db.workingx,db.resolvex,db.stash,db.haveg,db.workingg,db.locksg,db.resolveg,db.storagesh,db.storagesx,db.upgrades.rp,db.upgrades,db.scandir,db.scanctl,db.revstg,db.refcntadjust,db.have.pt"

4. Ensure you have a recent checkpoint of the commit server, or create a checkpoint on the commit server (see Checkpoint and journal options) that contains data specific to the edge server and takes account of any filters defined in the edge server spec:
   `p4d -r commitroot -P edge-serverid -jd globaledge.dump`

5. Move the edge database to a safe directory.

6. Copy the `globaledge.dump` checkpoint file from the commit server to the edge server.

7. Re-create the edge database from the checkpoint you created on the commit server.

   `p4d -r edgeroot -jr globaledge.dump`

   or

   If using a full checkpoint of the commit server:
   `p4d -r edgeroot -R edge-server -jr master.ckp.256`

   where `256` represents the commit server's most recent checkpoint number.

   With `p4d -r edgeroot -R edge-server -jr master.ckp.256`, any filtering defined in the edge server spec is ignored. This might result in the edge server containing more metadata than the server spec definition.

8. If `db.view` exists in the edge server's P4ROOT directory, (`edgeroot` in this example), rename `db.view` to `db.view-from-commit`

9. Restore the edge-specific data:
   `p4d -r edgeroot -jr edgedump`

10. Move the `db.*.rp` files from the safe directory to the edge server's `P4Root` directory, overwriting those files if they already already exist.

11. Start the edge server.

12. Allow the edge server to catch up with the commit server and check this with the

        p4 pull -l -j

    command issued against the edge server. The output might be similar to:

        Current replica journal state is: Journal 256, Sequence 1251.
        Current master journal state is: Journal 256, Sequence 1251.
        The statefile was last modified at: 2022/03/25 14:48:41.
        The replica server time is currently: 2022/03/25 14:48:50 +0000 GMT

13. Enable access to edge server users.

14. Check that archive files are up to date on the edge server:
    `p4 verify -q -t //...`

### If a new checkpoint cannot be taken

If a new checkpoint cannot be taken of the commit server or read-only replica of the commit server (see Step 4 above), use the last good checkpoint. This could require one or more numbered journal files as well as the current journal file. For example, to restore numbered journals and a running journal where the last good checkpoint was `master.ckp.254`:

    p4d -r edgeroot -R edge-server -jr master.ckp.254 journal.254 journal.255 journal

Failing to filter the journals correctly might cause consistency issues with workspaces, failed operations, or data loss.

Any filtering defined in the edge server spec is ignored. This might result in the edge server containing more metadata than the server spec definition.

Your search for returned results