Proxmox VE / Advanced: coordination and recovery evidence / Lesson 18

Capstone: upgrade and recovery review

Assemble a release-specific maintenance review that protects data, ownership and recovery while distinguishing a paper plan from completed operational checks.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Integrate inventory, compatibility, backup and failure-domain evidence.
Define maintenance gates and user-service acceptance.
Write an honest handoff with explicit unexecuted checks.

State the maintenance scenario

The capstone reviews a hypothetical maintenance change for three teaching hosts carrying a catalog VM and a container worker. It does not prescribe an upgrade command or claim a particular installed version. The plan must identify the actual source and target release, supported upgrade path, guest compatibility, storage dependencies and recovery objectives before an operator acts. Minor updates and major release transitions have different prerequisites. Read the exact vendor procedure for the selected path rather than assembling a universal recipe from old examples. The user-service goal is correct catalog responses with preserved data, not merely a successful package transaction.

Assemble the evidence gates

The first record lists gates that need evidence and owners. A backup job alone is insufficient; recovery viability includes accessible copies, keys and a validated application restore. Cluster maintenance must preserve quorum assumptions and account for HA behavior and survivor capacity. Storage health and compatibility remain separate from management health. The record is intentionally not a sequence to execute. Its purpose is to make missing prerequisites visible while there is still time to revise the design, rather than discovering them after one node or storage path has already become unavailable.

text Unexecuted maintenance gates

gate1: exact source/target release and official supported procedure
gate2: inventory + guest/device/storage/network compatibility
gate3: recoverable copies + keys + application restore evidence
gate4: quorum/HA/fencing and survivor-capacity review
gate5: approved change owner, recovery path and user acceptance

These are review obligations. They do not grant permission, execute checks or establish a live cluster state.

Compare intended and observed state

A change review should identify which guests move, which disks remain accessible, which network identities stay stable and which compatibility assumptions change. Before-and-after evidence needs timestamps and exact resource identities. The second program compares a tiny synthetic inventory for missing guest IDs. It does not query Proxmox or prove the surviving guests are healthy. An inventory match is a necessary bookkeeping invariant, while application correctness, storage integrity and policy enforcement need their own acceptance checks. Do not expand a simple set comparison into a claim that maintenance completed safely.

python Synthetic post-change inventory check

expected_guests = {210, 220, 230}
observed_fixture = {210, 220}
print(sorted(expected_guests - observed_fixture))
print(expected_guests == observed_fixture)

Expected output

[230]
False

Guest230 is missing from this fixture and the sets differ. No guest state is discovered or changed.

Plan recovery from consequences

Recovery depends on what changed: guest configuration, host packages, kernel, storage metadata and external application state have different reversibility. Do not promise a package downgrade as a universal rollback strategy. A restore may need another compatible host and isolated identities; a cluster partition needs ownership and quorum evidence; a failed application migration needs data-aware recovery. Define stopping conditions for uncertainty and avoid competing corrective changes. A maintenance window should preserve independent access and evidence even if the normal management path fails, so the recovery plan remains usable when its assumptions are tested.

Deliver a bounded handoff

The final handoff identifies intended outcomes, reviewed official references, assumptions, local calculations actually executed and all unexecuted platform checks. This course performs no installation, update, cluster action, guest operation, backup, restore, network probe or storage change. Its examples are synthetic and its platform records remain non-runnable. A complete local learning artifact can still be rigorous: it exposes the chain from requirements to capacity, identity, ownership and recovery evidence. The next authorized environment review can then address named questions rather than treating educational snippets as a tested operational runbook.

Common errors and fixes

A generic upgrade recipe replaces release-specific guidance

Why it happens: Source/target compatibility and prerequisites were not identified.
How to fix it: Use the official procedure for the exact supported transition.
Prevent it next time: Record release assumptions and review date in the plan.

Matching inventory is treated as full maintenance acceptance

Why it happens: Bookkeeping replaced application and data evidence.
How to fix it: Verify explicit service, storage and policy invariants separately.
Prevent it next time: Assign an evidence boundary to every gate.

Downgrade is promised without reviewing state changes

Why it happens: Different components were assumed equally reversible.
How to fix it: Assess supported recovery for packages, storage and application data individually.
Prevent it next time: Prepare recovery before the change, including independent access.

Check your understanding

1. The inventory sets match after maintenance. Which important claims remain open?

Show worked solution

Guest boot and driver compatibility, storage integrity, network paths, authorization, backup freshness and application behavior remain unproven by that comparison. Use it as one bookkeeping check and collect each required acceptance result separately. Record exact tools and observations rather than converting an inventory match into a statement that all workloads are healthy.

2. What must a handoff say when only offline Python models ran?