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

P4 Server Administration Documentation | 2025.1

# Backup and recovery planning

A commit server can use the same backup and high availability / disaster recovery (HA/DR) strategy as a central server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'. that is not a commit server. However, edge servers contain unique information and should have their own backup and a HA/DR plan.

Whether an edge server outage is as urgent as a central server outage depends on your requirements. An edge server might have a HA/DR plan with a less ambitious Recovery Point Objective (RPO) and Recovery Time Objective (RTO) than the commit server.

If you are planning for Failover, make sure that the edge servers will be redirected to use the new commit server.

If a commit server must be rebuilt from backups, each edge server must be rolled back to a backup prior to the commit server’s backup.

Alternatively, if your commit server has no local users, the commit server can be rebuilt from a fully-replicated edge server. In this scenario, the edge server is a superset of the commit server.

Backing up and recovering an edge server is similar to backing up and restoring a replica server.

## Time considerations

Avoid allowing checkpoints to occur simultaneously on multiple edge servers.

Expect that each edge server checkpoint might take significantly longer than a checkpoint on commit server with no local users.

Journal rotations for edge servers can occur at the same time as journal rotations for commit servers.

## Backup considerations

We recommend that you use OS backup utilities to make a copy of:

- Any shelved file content, unloaded clients and labels, and spec depot entries for clients and labels that have been created on this edge server.

- The `state` and `server.id` files from the P4ROOT directory. To learn more, see p4 serverid in the P4 CLI Reference.

## Steps for backing up an edge server

1. On the edge server, schedule a checkpoint to be taken the next time journal rotation is detected on the commit server. For example:

       p4 -p myedgehost:myedgeport admin checkpoint

   This causes a `stateCKP` file to be written to the `P4ROOT` directory of the edge server, recording the scheduling of the checkpoint. The p4 pull command performs the checkpoint at the next detected rotation of the journal on the commit server.

   Where multiple edge servers are working with a commit server, try to stagger the checkpoints so they do not all occur at the same time.

2. Rotate the journal on the commit server:

       p4 -p mycommithost:mycommitport admin journal

The edge server will automatically resume processing user commands when the checkpoint has finished.

Your search for returned results