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 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 an 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 edge servers can be redirected to use the replacement commit server.

If a commit server must be restored from backups, the recovery requirements for connected edge servers depend on the recovery point achieved for the commit server. If the commit server can be fully restored by applying the required checkpoints and journals, edge servers typically do not need to be rolled back. Rollback of edge servers is only required if the commit server cannot be recovered to the required state and consistency between the commit and edge servers cannot be maintained.

If the commit server has no local users, it can be rebuilt from a fully replicated edge server because the edge server contains a superset of the commit server's data.

Edge servers have their own backup and recovery requirements. To learn more, see Steps for backing up an edge server.

Time considerations

When scheduling checkpoints on multiple edge servers, consider the impact of checkpoint activity on system resources, storage performance, network bandwidth, and maintenance windows. Depending on your environment, checkpoints can be scheduled simultaneously or staggered to meet operational requirements.

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

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, schedule checkpoints according to the capacity and maintenance requirements of your environment.

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.