Replica repair and storage evacuation
Replace missing replicas without discarding authoritative volume data.
Replica repair copies authoritative volume blocks to eligible storage locations when redundancy falls below the volume's policy. Evacuation uses the same copy mechanism to remove a healthy location deliberately.
Read the replica set
Open Volume → Replicas. Each replica records its node, device, failure domain, generation, synchronization state, and last observation. A replica can be healthy, copying, unavailable, or stale. An unavailable replica has not necessarily lost its data; a stale replica is not current enough to become a writer automatically.
The volume health condition identifies whether the remaining set still meets its write requirement. Read availability and redundancy separately. A writable degraded volume still needs repair; an unreadable volume requires recovery, not merely acknowledgement of the alert.
Repair admission
Infra chooses a destination that satisfies the storage policy's node, rack, or zone separation. It reserves the required space before copying. Pool-wide free space is insufficient when all eligible devices are in an already occupied failure domain.
Repair remains blocked when no compliant destination exists. Adding space to the wrong zone does not clear that blocker. Provide suitable capacity or make an explicitly reviewed policy transition; the repair worker does not reduce replica count on its own.
Copy and verification
A repair starts from a selected current generation and tracks changes made during the copy. The new replica does not count toward the write requirement until its synchronization and verification steps finish. Transferred bytes alone do not establish a healthy replica.
A canceled repair removes its incomplete destination after ownership checks. It leaves the existing authoritative set in place. If the source disappears, repair pauses or fails with the observed source generation rather than declaring a partial target authoritative.
Evacuate a device
Use the Storage pool API to request an evacuation preview for the device. Review its volume and snapshot dependencies, then submit the preview to start evacuation. Admission is restricted before copying begins.
During the copy, check Volume → Replicas for replacement state and the pool's repair view for backlog. Existing writes can continue while the remaining set meets its write requirement. Compare foreground latency with its pre-evacuation level before starting more copies.
Do not physically remove the device until no required replica or snapshot block depends on it. Compute drain and storage evacuation are separate operations even when they target the same host.
Forced recovery
If no current replica set satisfies the write requirement, automatic repair cannot infer which divergent data the application should retain. Recovery Override permission permits a reviewed source-generation selection only after the old writers are fenced.
The recovery record identifies discarded generations and the operator's reason. A recovered filesystem can still require application consistency checks. Prefer verified backup restoration when authoritative live data cannot be established.
Use Storage pool API to inspect repair blockers and storage performance to bound repair traffic.