Partition and HA recovery evidence

Understand the likely causes

• Possible causes include a communication partition, actual host failure, quorum loss, fencing still in progress, missing target data or no feasible survivor capacity. These causes require different evidence and must not be collapsed into one failed-node label.

Preserve separated observations

Record membership and quorum observations with collection time, plus separate guest execution and storage-access evidence from authorized owners. An unreachable management endpoint does not prove the node lost power or stopped writing shared disks. Avoid competing corrective changes while the outcome remains uncertain. This guide uses a synthetic incident record and contacts no cluster service. The immediate learning task is to identify the missing proof: coordinated decision authority, exclusive execution ownership, data availability or feasible placement. Each question belongs to a different part of the recovery contract.

Separate votes from data safety

Quorum supports coordinated configuration decisions; fencing addresses the risk that a former owner still executes and writes. They are related prerequisites, not substitutes. The following record makes that distinction explicit. A local majority calculation cannot authorize a new writable instance, and changing expected votes does not establish what another partition is doing. Do not move configuration files, bypass ownership protection or restart the same guest elsewhere merely to make an interface look responsive. Those actions require a release-specific approved recovery procedure grounded in actual state.

membership question: which partition can coordinate changes?
ownership question: can the former guest owner still execute/write?
data question: which target has a usable recovery point?
placement question: which eligible survivor has enough resources?

Assess recovery feasibility

After the approved design establishes safe ownership, recovery still needs accessible disks, compatible target devices and enough survivor resources. Scheduled replicas can be older than the desired recovery point, and shared storage can be reachable but degraded. Placement rules can eliminate otherwise capable nodes. Review the application’s data-loss tolerance and startup requirements alongside these constraints. A guest that eventually runs may still fail application acceptance. This diagnosis therefore continues beyond the HA status line to the user-service boundary, with timestamps for each established milestone.

Handoff to the authorized recovery owner

The handoff should identify exact resources, observation times, unresolved ownership, last usable data and target capacity constraints. Preserve uncertainty instead of replacing it with a forced-progress assumption. This guide executes no quorum override, fencing action, failover or node operation and includes no administrative command to copy. A real recovery decision belongs to the authorized owner using the selected release’s documented procedure. The editorial result is complete when the evidence gaps and their consequences are clear, not when an unverified guest-start action has been proposed.

Keep it from recurring

• Maintain failure-domain diagrams, quorum and fencing assumptions, survivor budgets and application-aware recovery tests. Review shared network dependencies so storage recovery traffic cannot silently undermine cluster communication.