High availability (active-passive)¶
If a mail server fails, perform a controlled active-passive takeover. The admin console creates the failover request; nothing runs on the server without root approval.
Global administrator and rootAdmin console › Tools and Migration › Profelis HA
Monitoring¶
- Open Tools and Migration › Profelis HA. The This node and Peer node rows show each server's role (primary / standby), mailboxd and MariaDB status and disk usage.
- The Replication row shows the replication state and lag. The Services - This node section lists the services; stopped services are expected on the passive server.
- A failover request is created with Request Failover; the list below shows the requests and their steps.

Helper component
If the screen shows "zmcontrol status was not collected" instead of the services, profelis-ha-companion is not running on the server. This component, running as root, collects the status.
Manual failover¶
- Check the replication lag on the status screen and press Request Failover. Target host (new primary) is filled with the peer.
- Source host (old primary, for fencing) is the server that will be shut out.
- Enter a short explanation in Reason.
- While Dry run is ticked the steps are only logged and nothing changes; untick it for a real failover. Queue the request with OK. A request number appears.
- Approve on the server as root:
profelis-ha-companion confirm <request-no> - It is verified that the old primary is down (fencing), then the new server is made primary. Progress is followed step by step in the list. You can withdraw a pending request with Cancel Request.

Stops if fencing cannot be verified
If it cannot be proven that the old primary is down, the process stops (to avoid split brain). Fix the network or power-off path and create a new request; the old request does not continue by itself.
Scope
Active-active operation and automatic failover are not part of this module. For active-active, see Always On.