Watch: protecting a container, every option
Choosing the node and container, replica nodes and priority, sync interval, and the automatic-failover options: witness and timeout. The written guide is below.
Overview
WolfHA keeps an LXC container available when the node running it dies. Protect a container from the WolfHA page in your cluster’s sidebar, pick one or more standby nodes, and WolfStack replicates the container’s filesystem to them on a schedule. Every standby is a stopped copy with the container’s exact identity — same name, same MAC address, same IP, same WolfNet address. When the primary node fails, a standby takes over wholesale: DNS never changes, clients never re-resolve, and no load balancer is involved.
Failover is one click — or, with automatic failover enabled, no clicks at all: in live testing a standby detected node death, passed every safety gate, and had the container answering on its IP again in 72 seconds.
There is nothing to provision first: no shared storage, no SSH keys between nodes, no third quorum machine. Replication runs over the same encrypted channel the cluster already uses, and two-node clusters are fully supported.
Protecting a container
- Open WolfHA under your cluster in the sidebar and click + Protect a container.
- Pick the node the container runs on, the container, and the standby node(s). The order you tick standbys is the succession order — the first is preferred at failover.
- Choose a sync interval (default 5 minutes) and, optionally, enable automatic failover with a witness IP.
WolfStack takes a live snapshot of the container’s root filesystem — the container keeps running — and seeds each standby. From then on, only changes travel: each round, the standby reports a manifest of what it has, and the primary ships just the files that differ, plus deletions, preserving ownership, extended attributes and file capabilities exactly. A container that has not changed sends a tiny heartbeat instead, so settings updates and freshness tracking never wait for a file to change.
The WolfHA page shows every protected container with its copies, roles, and per-standby sync age. If a standby starts falling behind, WolfStack raises one alert when the syncs begin failing — worded for what it actually means: your failover point is ageing — and one more when they recover.
Failover and failback — one button, both directions
Promote on any standby makes it the active copy, and the same button performs failback later. It behaves according to what is actually possible:
- Planned move / failback (old primary reachable): a coordinated, lossless handoff. The old primary stops the container, pushes one final delta of the quiesced filesystem, and demotes itself — then the standby starts. Changes written seconds before the click arrive intact.
- Disaster (old primary dead): takeover with the state of the last completed sync. The dialog tells you which of the two it is about to do, and how old the standby’s copy is, before you confirm.
When the failed node comes back — whether it reboots or just restarts its agent — it discovers the container is active elsewhere, demotes its own stale copy automatically, and catches back up from the new primary’s sync rounds. Failing back is simply pressing Promote on the original node once it has caught up: same lossless handoff, in reverse.
Automatic failover — five gates instead of a quorum
Most HA systems need a quorum, which quietly rules out the most common cluster size there is: two nodes. WolfHA replaces quorum with five independent safety gates, every one of which must pass before a standby promotes itself:
| Gate | Question it answers |
|---|---|
| 1. Witness | Can I reach the witness IP (normally your gateway)? A node that can’t is the isolated one — it holds still. |
| 2. Cluster view | Does the rest of the cluster also think the primary is gone? If gossip still sees it alive, only my path to it is broken — refuse, and alert the operator instead. |
| 3. Succession | Is a healthier standby ahead of me in the priority order? Then it’s their job — defer. |
| 4. Freshness | Is my copy recent enough to be worth running? An ancient copy alerts you to decide, rather than silently resurrecting last week’s data. |
| 5. The bridge itself | Does the container’s own IP still answer on the network? If anything responds, the container is alive somewhere — abort. On a shared bridge, the resource is its own lock. |
On the other side, the primary self-fences: if it loses both the witness and every standby for half the failover window, it stops its own HA containers before any standby would start them — so a network partition never ends with two copies of the same container fighting over one IP. A witness outage alone (say, the gateway reboots) does not fence a healthy primary: if the standbys still answer, the container keeps running and you get an alert that automatic failover is suspended until the witness returns.
Set the failover window to taste (default 90 seconds; the primary fences at half that). Enable it per container — a container you’d rather fail over by hand can stay manual forever.
Safety rails
- Standbys can’t start by accident. They carry no autostart flag, boot-time autostart never sees them, and trying to start one by hand from the containers page is refused with a pointer to Promote — because a standby shares the primary’s MAC and IP, and two of those on one network is the exact disaster HA exists to prevent.
- A returning primary asks before it starts. After a reboot, an HA primary first asks every standby “did anyone take over while I was down?” If yes, it demotes itself instead of starting.
- Standby copies are visibly badged (“HA standby”) in the container lists, so a stopped duplicate never looks like a mystery.
- Duplicate detection converges. If both copies are ever found running, the standby copy stops itself and raises an alert — the incumbent wins.
Being honest about the trade-offs
- A failover carries the last completed sync. Up to one sync interval of recent changes can be lost in a disaster failover (a planned handoff loses nothing). The UI states this plainly wherever it applies.
- Databases deserve their own replication. File-level sync of a live database is crash-consistent at best — MariaDB, PostgreSQL and friends should replicate at the database layer (see Galera clustering), with WolfHA protecting everything around them.
- Same-IP takeover wants a shared Layer 2. The seamless no-DNS-change story assumes your nodes share a bridge — a Hetzner vSwitch, OVH vRack, or any common VLAN (see Networking). It also gives gate 5 its authority. Put the witness on that same network — the bridge’s gateway is the natural choice.
- WolfHA reacts to node failure, not application crashes. A container the operator stopped stays stopped — WolfHA never second-guesses intent.
- Scope: native LXC containers on native WolfStack nodes. Proxmox-managed containers store their rootfs on LVM/ZFS volumes rather than a plain directory, so they are not yet supported as primaries or standbys.
How it compares
| WolfHA | Typical HA stacks | |
|---|---|---|
| Minimum nodes | 2 | 3 (quorum) |
| Shared storage | Not required | Usually required (Ceph/NFS/DRBD) |
| Setup | One dialog | Fencing devices, cluster resource managers, config files |
| Identity after failover | Same name, MAC and IP — DNS untouched | Often a new IP behind a load balancer or VIP daemon |
| Split-brain defence | Witness + self-fencing + the container’s own IP as a lock | Quorum + dedicated fencing hardware |
Quick start
- Two or more WolfStack nodes in a cluster (see Multi-Server Clustering), ideally sharing a bridge for seamless same-IP takeover.
- Cluster sidebar → WolfHA → + Protect a container.
- Watch the first seed complete and the per-standby sync ages tick over.
- Try it: press Promote on the standby, watch the lossless handoff, then promote back. Nothing teaches confidence in a failover system like performing one on purpose.
WolfHA ships in WolfStack v25.11.0 and later — install or update.