Plan recovery: WZ-IT supports Proxmox disaster recovery. A scoped restore test checks an agreed recovery path. Arrange an initial meeting.
A disaster recovery plan defines which systems should recover from which data point after a particular failure. The following patterns support planning; they are no promised recovery time. As of October 2026.
Contents
- Objectives and failure boundaries
- Three technical patterns
- Multi-site and stretched Ceph
- Recovery runbook
- Acceptance and service scope
- Sources
Objectives and failure boundaries
Define the maximum acceptable data loss as RPO and the acceptable interruption as RTO for each application. These objectives initially describe requirements. Whether the architecture meets them must be checked for the agreed scenario. Record host failure, storage loss, site loss and unusable data separately. Each case requires a reachable copy and a controlled startup path.
HA and fencing coordinate recovery of HA resources within the cluster. A cluster at one site does not remove that site's shared failure causes. Document power, switches, administrator access and backup dependencies as well.
Three technical patterns
| Pattern | Data path | Planning boundary |
|---|---|---|
| Backup and restore | Retained guest backups, separate offsite copy, replacement PVE | Host, networks and applications need recovery |
| ZFS replication | Asynchronous copies of local ZFS guest volumes to other cluster nodes | Last successful sync limits the available data point |
| Stretched Ceph | Storage placement across sites with a separate quorum design | Storage availability does not replace independent backups |
The PVE backup documentation covers guest backups and restore. Loss of the PVE installation additionally requires host recovery. A PBS reachable only through the failed infrastructure is not an independent recovery path; include its accessibility and the offsite copy in the plan.
Storage replication uses local ZFS. HA with replication can lose writes since the last sync. A replica therefore does not promise zero RPO. After a failure, the data point and application consistency require separate assessment.
Multi-site and stretched Ceph
Distinguish two independent clusters with planned restore or data transfer from one shared cluster spanning sites. A shared PVE cluster still has to meet the Corosync network requirements. A site connection with sufficient bandwidth can still have excessive or fluctuating latency. The provider-neutral network guide explains traffic separation.
Explicitly enabled Ceph stretch mode places OSDs at exactly two data sites and uses two monitors per data site plus a tiebreaker monitor at a third location. It requires a matching CRUSH rule and four replicas, two per data site; erasure-coded pools are excluded in this mode. These requirements apply to the documented stretch mode, not to every distributed Ceph topology.
Corosync quorum needs an additional design. A QDevice replaces neither Ceph monitors nor data copies. Loss of connectivity while both sites remain operational must be an explicit test scenario. Stretched Ceph does not automatically protect against deletion or compromised administrator access. Changes to stretch mode need version-specific planning rather than a general emergency recipe.
Recovery runbook
Fill this template with actual systems, owners and evidence:
| Step | Information to record |
|---|---|
| Authorisation | Failure scenario, decision maker, abort criterion and communication |
| Secure source | Shut down or fence the old site or host; prevent duplicate starts |
| Foundations | Restore management access, DNS, time service, network, storage and PBS connectivity |
| Select data point | Assess available backup or replica, keys, consistency and missing changes |
| Recovery | Start infrastructure dependencies before applications; specify the exact order |
| Acceptance | Verify data point, login, business workflow, access and new backups |
| Return | Establish write authority, reconcile data and separately approve failback |
The pmxcfs recovery chapter requires the failed node to be safely powered off or fenced before manual guest recovery. A configuration file alone does not make missing local guest disks available. These prerequisites belong before every manual start.
Acceptance and service scope
Record the data point used, the start of recovery, business acceptance and unresolved dependencies. An actually measured duration applies to the checked configuration and selected scenario. Missing keys, inaccessible backups or unavailable replacement capacity are findings, not passed partial tests.
For objectives, architecture and a runbook, use disaster recovery. For an isolated check of a backup point, use a restore test. Scope and acceptance criteria are agreed explicitly.
