Deploy a production-ready Proxmox VE host with storage, networking, backups, and recovery
Install verified Proxmox VE 9.2 on supported bare metal, validate ZFS and VLAN bridges, harden management, update safely, protect guests with PBS, and prove guest plus bare-metal recovery.
Operate a secure, supportable single Proxmox host whose storage, networking and access are observable and whose workloads can be recovered independently.
- Proxmox VE 9.2
- Debian 13.5 base supplied by Proxmox VE 9.2
- Supported bare metal and console Vendor-supported server, firmware, direct disks, ECC, UPS, NICs, BMC and serial/port inventory are approved.
- Network, storage and security design Canonical DNS/time, management/guest VLANs, bridge/MTU, ZFS topology/reserve, roles/MFA/firewall/TLS and capacity are approved.
- Independent backup and recovery Off-host PBS, protected token/encryption key, offsite sync, restore storage/bridge, spare host and application checks exist.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A production single-node Proxmox VE 9.2 host installed from the verified 9.2-1 ISO, with direct-disk ZFS health/capacity controls, canonical management identity, VLAN-aware bridge networking, official repositories, controlled updates, MFA/role/firewall/TLS boundaries, and hardware-console recovery.
- An independent Proxmox Backup Server protection path with restricted credentials and separately recoverable encryption keys, application-aware scheduled guest backups, isolated guest restore, and a complete bare-metal host rebuild drill.
- The node and ZFS pool match exact hardware/serial inventory, management stays restricted and recoverable, guest VLANs pass intended and denied tests, and only supported signed PVE/Debian packages are installed.
- Named MFA administrators have scoped roles while untrusted networks cannot reach SSH, API or BMC and external clients validate the management certificate hostname/chain.
- A selected PBS archive restores a unique VM into an isolated network with application integrity, and a spare-host rebuild reconstructs network, storage, access, backup trust and one guest within RPO/RTO.
Architecture
How the parts fit together
Proxmox VE 9.2 runs directly on supported bare metal using Debian 13.5, a PVE kernel, KVM/QEMU, LXC and pmxcfs. Direct disks form a monitored ZFS pool with reserved capacity. A VLAN-aware Linux bridge connects reviewed guest VLANs while BMC and management remain protected. Official repositories deliver signed updates. Named MFA identities and PVE/upstream firewalls guard API/SSH. Off-host PBS stores encrypted, verified, retained and offsite-synchronized guest backups; protected host configuration plus a spare server enables bare-metal recovery.
- Operators verify installer digest and destructive targets, install PVE 9.2, then validate hardware, identity, time, TLS and ZFS before workloads.
- Console-protected bridge changes create management and guest connectivity; allowed and forbidden VLAN paths prove segmentation.
- Official repositories and controlled upgrades keep the node current while MFA, roles, firewall and trusted certificate protect management.
- Guest agent/application hooks precede PBS backup; PBS verifies storage and syncs offsite.
- An unused VMID and isolated bridge receive a real restore, while a separate annual drill reinstalls the host and restores a guest/application.
Assumptions
- Server, firmware, CPU virtualization/IOMMU, ECC memory, HBA/NVMe, UPS, NIC and BMC are vendor-supported and their serial/port map is authoritative.
- The node is intentionally single-host; owners accept no automatic host failover and have spare hardware plus achievable restore RTO.
- ZFS has direct disk visibility, correct topology, sufficient RAM and at least the documented operational capacity reserve.
- Canonical forward/reverse DNS, synchronized time, protected BMC/management VLAN, upstream trunk/MTU and external TLS trust are controlled.
- PBS is off-host with separate failure domain, restricted identity, monitored capacity, protected encryption key and offsite copy.
- Transactional guests expose supported application backup/quiescing and integrity checks in addition to VM-level backup.
Key concepts
- pmxcfs
- Proxmox cluster filesystem exposing configuration under `/etc/pve`; it has service/version semantics and must not be restored by blind live file overwrite.
- ZFS mirror
- Redundant vdev that tolerates one member loss and repairs checksummed data; it does not protect deletion, compromise or host/site loss.
- VLAN-aware bridge
- Linux bridge that filters and carries configured VLANs between guest vNICs and an upstream trunk.
- vzdump snapshot mode
- PVE guest backup mode that can back up a running VM; application consistency still depends on guest/application integration.
- PBS verification
- Checks backup datastore chunks and index integrity; it complements but cannot replace an application-level restore.
- bare-metal recovery
- Reinstallation and reconstruction of host network, storage, identity, firewall and backup trust before isolated guest restoration.
Before you copy
Values used in this guide
{{proxmoxIsoPath}}Official verified Proxmox VE 9.2-1 ISO.
Example: /srv/iso/proxmox-ve_9.2-1.iso{{installerDevice}}secretTwo-person verified removable installer target.
Example: /dev/disk/by-id/usb-SanDisk_Ultra_ABC123-0:0{{managementFqdn}}Canonical management FQDN.
Example: pve01.example.net{{managementAddress}}Stable management address.
Example: 10.20.0.11{{managementCidr}}Static management address and prefix.
Example: 10.20.0.11/24{{managementGateway}}Reviewed management default gateway.
Example: 10.20.0.1{{physicalNic}}Mapped physical interface used by vmbr0.
Example: eno1{{allowedVlans}}Management and guest VLAN allowlist.
Example: 20 110 120{{guestVlan}}Canary guest VLAN.
Example: 110{{bridgeMtu}}End-to-end verified bridge MTU.
Example: 1500{{zpoolName}}Primary ZFS pool.
Example: rpool{{diskDevice}}Stable by-id disk inspected by SMART.
Example: /dev/disk/by-id/nvme-SAMSUNG_MZQL23T8HCLS_AAA123{{backupStorage}}PVE storage ID for off-host PBS.
Example: backup-pbs{{backupSchedule}}PVE calendar schedule.
Example: daily 01:00{{testVmId}}Canary production VMID.
Example: 100{{backupVolumeId}}Exact selected PBS backup volume ID.
Example: backup-pbs:backup/vm/100/2026-07-28T01:00:02Z{{restoreVmId}}Unused restore drill VMID.
Example: 9100{{restoreStorage}}Dedicated restore target storage.
Example: restore-zfs{{isolatedBridge}}Non-routed restore bridge.
Example: vmbr99{{hostConfigArchive}}secretEncrypted protected host recovery archive.
Example: /root/recovery/pve01-config-20260728.tgzSecurity and production boundaries
- Keep hypervisor and application management interfaces off untrusted networks. Restrict by firewall and administrative source, require TLS hostname validation and MFA where supported, and never expose management simply because the web interface has authentication.
- Separate service availability from recoverability. RAID, ZFS mirrors, replication, snapshots, VM checkpoints, database replicas, and application maintenance mode remain inside related failure domains and do not replace an independent tested backup.
- Before destructive storage, database, network, certificate, or restore operations, require two-person target verification, current backups, independent console access, capacity headroom, application quiescing, and explicit stop/rollback criteria.
- Capture examples using synthetic identifiers and data. Redact host serials, MACs where sensitive, internal addresses, usernames, paths revealing tenants, tokens, passwords, encryption keys, recovery keys, and file content.
Stop before continuing if
- Stop before installation or media writing until exact device serials and destructive targets are verified by two operators.
- Stop when BMC/management recovery, DNS/time/TLS, storage topology/health/reserve, bridge/VLAN/MTU, repositories or hardware support differ.
- Stop guest onboarding if MFA/roles/firewall/TLS or off-host PBS encryption-key recovery is incomplete.
- Stop release until both isolated guest restore and spare-host rebuild with application verification meet RPO/RTO.
decision
Approve hardware, storage, network, identity, backup, and recovery design
Record the exact server model, firmware, CPU virtualization/IOMMU, memory with ECC, storage controllers and every disk serial, boot redundancy, ZFS/LVM choice, UPS, management/BMC path, bridges/bonds/VLANs/MTU, canonical FQDN and static address, time/DNS, repository entitlement, administrative roles/MFA, firewall, guest capacity/reserve, Proxmox Backup Server target, encryption-key custody, RPO/RTO, and bare-metal recovery drill. This guide targets a production single host; it does not claim single-node availability.
Why this step matters
The Proxmox ISO consumes selected disks and the host becomes the root of trust for every guest. A production design must establish destructive targets, failure domains, management recovery, capacity reserve, and restore evidence before installation.
What to understand
A single host can be operationally robust but cannot provide host-level HA; workloads needing automatic failover require a separately designed quorum cluster and shared/replicated storage.
ZFS wants direct disk visibility and memory; do not layer it casually over a write-back hardware RAID virtual disk.
Backup encryption keys and PBS credentials must be recoverable independently of the PVE host being lost.
System changes
- Creates an approved build, capacity, access, backup, and recovery record; no host changes.
Syntax explained
Proxmox VE 9.2- Current reviewed production baseline released 2026-05-21 and based on Debian 13.5.
single host- No automatic host failover; RTO depends on spare hardware and verified restore.
Build approved: Proxmox VE 9.2-1; server=R7615 asset HV-014; BMC isolated; 2x mirrored boot SSD; 4x NVMe ZFS mirror pairs, ashift=12, autotrim=on; vmbr0 VLAN-aware on bond0; management VLAN 20; guest VLANs 110/120; PBS off-host+offsite sync; nightly backup; monthly verify; quarterly isolated VM restore; annual host rebuild.
Checkpoint: Checkpoint: Approve hardware, storage, network, identity, backup, and recovery design
Continue whenHardware/network/storage/security/application owners approve exact disk and port maps, capacity reserve, backup encryption custody, RPO/RTO and restore target.
Stop whenDisk serials, BMC access, UPS, supported hardware, independent backup/keys, or realistic single-host recovery are missing.
If this step fails
A bare-metal recovery has guests but lacks correct host network, storage, firewall, users, or keys.
Likely causeOnly guest archives were protected; host-specific configuration, inventory, encryption material, PBS fingerprint, and recovery instructions were absent or stale.
Compare `/etc/network/interfaces`, `/etc/pve/storage.cfg`, firewall and user/role exports with the protected build record.pvesm statuspve-firewall statuspveum user list
ResolutionKeep recovered guests isolated, rebuild the host from approved inventory and protected configuration/keys, validate each layer, then restore guests and rotate uncertain credentials.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop when hardware, identity, DNS, time, storage, network, certificate, backup, version, or ownership evidence differs from the approved plan.
- Stop when independent console/recovery, current backup, restore capacity, or a named rollback owner is unavailable.
verification
Download and verify the official Proxmox VE 9.2 installer
Download ISO 9.2-1 and the published SHA-256 value from the official Proxmox downloads page on a trusted workstation, calculate the image digest, compare every character, write it to controlled installation media, and verify the written media. Record image version, digest, workstation, operator, and target asset.
Why this step matters
The published digest authenticates the selected official image when obtained through a separately trusted channel. `dd` is destructive, so device identity requires the same two-person discipline as server installation.
What to understand
The reviewed official SHA-256 for the 9.2-1 ISO is recorded in the Proxmox downloads page; re-check it at deployment time.
Use `/dev/disk/by-id` or removable-media inventory to identify the installer device and disconnect unrelated writable disks when practical.
Digest the media/image again after writing where tooling permits; a successful write count alone is not verification.
System changes
- Overwrites the selected removable installer device with the verified Proxmox ISO.
Syntax explained
sha256sum- Calculates the complete ISO digest for exact comparison with Proxmox's published value.
conv=fsync- Flushes written installer data before `dd` reports completion.
status=progress- Shows progress without exposing credentials or content.
Values stay on this page and are never sent or saved.
sha256sum {{proxmoxIsoPath}}; sudo dd if={{proxmoxIsoPath}} of={{installerDevice}} bs=4M conv=fsync status=progress; sudo blockdev --getsize64 {{installerDevice}}4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6c proxmox-ve_9.2-1.iso 1840254976 bytes copied, 96.4 s, 19.1 MB/s 1840254976
Checkpoint: Checkpoint: Download and verify the official Proxmox VE 9.2 installer
Continue whenISO digest exactly matches official value; installer media size/content verifies; device and target server are recorded.
Stop whenDigest differs, source is unofficial, installer device identity is ambiguous, or unrelated storage remains at risk.
If this step fails
The Proxmox installer cannot see the intended system disks.
Likely causeController mode or firmware is unsupported, disks are behind a hardware RAID abstraction, NVMe firmware is stale, or the selected HBA does not expose devices as planned.
Inspect firmware/BMC storage inventory and controller mode.lsblk -e7 -o NAME,SIZE,MODEL,SERIAL,TYPElspci -nnk | grep -A3 -Ei 'raid|sata|sas|nvme'
ResolutionStop installation, correct the vendor-supported controller/HBA and firmware design, then re-identify every disk by model/serial before allowing any erase.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop before `dd` until two operators verify the exact removable target path, model, serial, and capacity.
- Destroy and redownload media if either source or written digest differs from the official release.
command
Install Proxmox VE on the verified bare-metal target
Boot the signed media through local/BMC console, select only the approved boot disks, configure the reviewed ZFS mirror or ext4/LVM layout, country/timezone, unique strong root credential through the installer prompt, canonical FQDN, static management address, gateway, and resolver. Confirm the destructive summary against serial inventory before installation.
Why this step matters
The installer erases selected disks and establishes the host identity, storage, TLS/API endpoint and root access. Post-install commands prove the result but cannot undo a wrong disk selection.
What to understand
Enter the root password only into the installer UI; do not place it in kickstart-style logs, screenshots, notes, or this guide.
Use a resolvable FQDN with stable forward and reverse DNS. Renaming a deployed Proxmox node is disruptive and not an ordinary fix.
Keep the BMC console active until network, repository, storage and backup configuration are verified.
System changes
- Erases approved system disks, installs Debian 13/Proxmox VE 9.2, creates storage, root identity, host networking and reboots.
Syntax explained
ZFS mirror- Provides checksummed redundant boot/storage across two direct disks; still not a backup.
static management address- Keeps API/cluster/storage identity stable and compatible with canonical DNS.
pveversion -v; hostname --fqdn; findmnt /; lsblk -e7 -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS; zpool status -v 2>/dev/null || true; ip -br address; ip routeproxmox-ve: 9.2-1 (running kernel: 7.0.4-1-pve)
pve01.example.net
TARGET SOURCE FSTYPE OPTIONS
/ rpool/ROOT/pve-1 zfs rw,relatime,xattr,posixacl
pool: rpool
state: ONLINE
config:
mirror-0 ONLINE
nvme-eui.001... ONLINE
nvme-eui.002... ONLINE
vmbr0 UP 10.20.0.11/24
default via 10.20.0.1 dev vmbr0Checkpoint: Checkpoint: Install Proxmox VE on the verified bare-metal target
Continue whenPVE 9.2-1 boots, exact disks/layout and FQDN/address/gateway/DNS match plan, pool/filesystem healthy, BMC remains reachable.
Stop whenAny disk/serial, hostname, address, route, resolver, pool topology, or installed version differs.
If this step fails
The Proxmox installer cannot see the intended system disks.
Likely causeController mode or firmware is unsupported, disks are behind a hardware RAID abstraction, NVMe firmware is stale, or the selected HBA does not expose devices as planned.
Inspect firmware/BMC storage inventory and controller mode.lsblk -e7 -o NAME,SIZE,MODEL,SERIAL,TYPElspci -nnk | grep -A3 -Ei 'raid|sata|sas|nvme'
ResolutionStop installation, correct the vendor-supported controller/HBA and firmware design, then re-identify every disk by model/serial before allowing any erase.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Do not confirm installer erasure until two operators compare every selected disk serial to the approved destructive-target list.
- If post-install identity or pool is wrong, keep the host empty and reinstall correctly instead of building guests on a compromised baseline.
verification
Verify firmware, virtualization, time, DNS, certificates, and services
Patch vendor firmware only through its approved workflow, then capture CPU extensions/IOMMU, ECC and memory, disk health, canonical forward/reverse DNS, chrony time, TLS certificate, PVE services, kernel/boot status, and critical journal entries. Verify the web UI only by FQDN through the management network with hostname validation.
Why this step matters
Virtualization, passthrough, certificates, distributed configuration, scheduled jobs and logs depend on correct firmware, CPU features, stable identity and time. Catching defects before guests avoids complex migrations.
What to understand
The default self-signed certificate can be bootstrapped only through a controlled fingerprint comparison; production should use a trusted Proxmox-supported ACME/custom certificate workflow.
Do not expose port 8006 to the public internet. Use management VPN/jump hosts and firewall source restrictions.
Record SMART/NVMe health and schedule alerts; ZFS cannot compensate for invisible controller failures or ignored media errors.
System changes
- Read-only platform validation; vendor firmware work is a separate controlled prerequisite.
Syntax explained
pvenode cert info- Displays active node certificate metadata without private key.
journalctl -p err -b- Shows current-boot errors that a green web dashboard can miss.
Values stay on this page and are never sent or saved.
egrep -c '(vmx|svm)' /proc/cpuinfo; dmesg | grep -Ei 'DMAR|IOMMU' | head; hostname --fqdn; getent ahosts {{managementFqdn}}; getent hosts {{managementAddress}}; timedatectl; pvenode cert info; systemctl --failed; journalctl -p err -b --no-pager64 [ 0.421] AMD-Vi: IOMMU performance counters supported pve01.example.net 10.20.0.11 STREAM pve01.example.net 10.20.0.11 pve01.example.net System clock synchronized: yes NTP service: active Subject: CN=pve01.example.net No failed units.
Checkpoint: Checkpoint: Verify firmware, virtualization, time, DNS, certificates, and services
Continue whenVirtualization/IOMMU and memory/storage health pass; canonical DNS/time/TLS match; no failed services or unexplained critical events.
Stop whenVirtualization disabled, time/DNS inconsistent, certificate name wrong, hardware errors, failed PVE services, or management requires insecure TLS bypass.
If this step fails
The installed host boots but reports no virtualization extensions.
Likely causeIntel VT-x/AMD-V, VT-d/IOMMU, NX, or nested virtualization is disabled or unsupported by firmware/platform.
egrep -c '(vmx|svm)' /proc/cpuinfodmesg | grep -Ei 'kvm|iommu|dmar'pveversion -v
ResolutionEnable the exact vendor firmware features, update supported firmware if required, reboot, and prove KVM/IOMMU health before creating guests.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop when hardware, identity, DNS, time, storage, network, certificate, backup, version, or ownership evidence differs from the approved plan.
- Stop when independent console/recovery, current backup, restore capacity, or a named rollback owner is unavailable.
verification
Validate ZFS topology, properties, capacity reserve, SMART, scrub, and alerts
Inspect the installed pool by stable disk IDs, ashift, autotrim, compression, health, errors, fragmentation and free-space reserve. Map every vdev to a physical bay/serial, enable periodic scrub and SMART monitoring, and conduct an alarm delivery test. Never create a topology whose failure tolerance or expansion path is misunderstood.
Why this step matters
ONLINE alone is insufficient: wrong topology, unstable device names, ashift, exhausted capacity, silent media wear, stale scrub and missing alert delivery can still make recovery impossible.
What to understand
Keep substantial free capacity; ZFS performance and guest safety degrade as the pool approaches full. Define an operational warning and hard provisioning stop.
Mirrors improve replacement and random I/O behavior but do not protect deletion, compromise, host loss, pool bugs or site failure.
A scrub validates checksums and repairs from redundancy; monitor completion and errors rather than merely scheduling it.
System changes
- Reads storage state; enables autotrim/scrub/alert schedules only through the separately approved host policy.
Syntax explained
ashift=12- Uses 4 KiB sector alignment selected at pool creation and not normally changed later.
autotrim=on- Returns freed blocks to supporting SSD/NVMe devices; validate device/controller behavior.
zpool status -P- Shows full stable device paths for physical mapping.
Values stay on this page and are never sent or saved.
zpool status -P -v {{zpoolName}}; zpool get ashift,autotrim,autoexpand {{zpoolName}}; zfs get compression,atime,xattr,acltype {{zpoolName}}; zpool list {{zpoolName}}; ls -l /dev/disk/by-id/ | grep -E 'nvme|ata'; smartctl -x {{diskDevice}} | grep -E 'SMART overall|Critical Warning|Media and Data Integrity Errors|Percentage Used'pool: rpool state: ONLINE scan: scrub repaired 0B in 00:14:22 with 0 errors NAME STATE READ WRITE CKSUM mirror-0 ONLINE 0 0 0 /dev/disk/by-id/nvme-A ONLINE 0 0 0 /dev/disk/by-id/nvme-B ONLINE 0 0 0 rpool ashift 12 local rpool autotrim on local NAME SIZE ALLOC FREE FRAG CAP DEDUP HEALTH rpool 3.62T 412G 3.22T 3% 11% 1.00x ONLINE Critical Warning: 0x00 Media and Data Integrity Errors: 0
Checkpoint: Checkpoint: Validate ZFS topology, properties, capacity reserve, SMART, scrub, and alerts
Continue whenTopology and serial map match design, ONLINE with zero errors, ashift/properties correct, reserve above threshold, SMART clean, recent scrub and alert test pass.
Stop whenUnknown device, degraded/resilvering pool, checksum/media errors, wrong topology/ashift, unsafe capacity, or alerts fail.
If this step fails
ZFS pool is DEGRADED, FAULTED, or resilvering unexpectedly.
Likely causeA disk, cable, backplane, controller, ashift choice, or previous replacement has failed or the wrong device was selected.
zpool status -v {{zpoolName}}zpool events -v | tail -n 100smartctl -x {{diskDevice}}ls -l /dev/disk/by-id/
ResolutionStop workload growth, identify the exact by-id device, preserve evidence and backups, follow the reviewed replace/resilver procedure, and do not clear errors before understanding them.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop when hardware, identity, DNS, time, storage, network, certificate, backup, version, or ownership evidence differs from the approved plan.
- Stop when independent console/recovery, current backup, restore capacity, or a named rollback owner is unavailable.
config
Configure a VLAN-aware Linux bridge with protected management
Keep BMC/local console open, save the installer-generated network file, map immutable NIC MAC/PCI identity to interface names, and configure the reviewed bridge/bond/VLAN plan. This example keeps the management address on vmbr0 and trunks approved guest VLANs; a dedicated management bridge is safer when hardware permits.
Why this step matters
Reloading the bridge can sever the only management session or leak guest traffic across VLANs. Console, saved configuration and upstream switch coordination are mandatory.
What to understand
Use `ifreload -a` from ifupdown2 rather than restarting generic networking or rebooting blindly; validate syntax first with the supported tooling.
Bridge MTU must match bond, physical switch, routed path, storage and guests. Use 1500 unless an end-to-end jumbo design is proven.
Restrict `bridge-vids` to approved VLANs and set guest tags explicitly; VLAN-aware does not authorize every VLAN.
System changes
- Replaces host bridge configuration and, when applied, moves management/guest traffic through the reviewed physical interface and VLAN trunk.
Syntax explained
bridge-vlan-aware yes- Enables VLAN filtering/tag handling on the Linux bridge.
bridge-vids- Limits VLAN IDs admitted by the bridge.
bridge-stp off- Disables STP for a simple single-uplink design; redundant L2 designs require deliberate loop protection.
/etc/network/interfacesValues stay on this page and are never sent or saved.
auto lo
iface lo inet loopback
auto {{physicalNic}}
iface {{physicalNic}} inet manual
auto vmbr0
iface vmbr0 inet static
address {{managementCidr}}
gateway {{managementGateway}}
bridge-ports {{physicalNic}}
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids {{allowedVlans}}
mtu {{bridgeMtu}}
vmbr0 UP 10.20.0.11/24
10.20.0.0/24 dev vmbr0 proto kernel scope link src 10.20.0.11
default via 10.20.0.1 dev vmbr0
port vlan-id
vmbr0 1 PVID Egress Untagged
20
110
120Checkpoint: Checkpoint: Configure a VLAN-aware Linux bridge with protected management
Continue whenSaved rollback file exists; ifreload syntax and apply pass; BMC and management FQDN remain reachable; VLAN 20 plus approved guest VLANs work and forbidden VLAN fails.
Stop whenInterface identity, upstream trunk, gateway, MTU, BMC access or negative VLAN test is uncertain.
If this step fails
The host becomes unreachable after applying bridge networking.
Likely causeThe physical interface name, VLAN-aware setting, address/gateway, bond, switch trunk, MTU, or management path differs from the reviewed design.
ip -br linkip -br addressip routecat /etc/network/interfacesbridge vlan show
ResolutionUse BMC/local console, restore the versioned interfaces file with `ifreload -a`, then correct the physical switch and host design before retrying.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Use a dedicated management NIC/bridge and a bonded VLAN-aware guest bridge when hardware and switch design provide separation/redundancy.
Stop conditions
- Keep BMC/local console open and copy the known-good interfaces file before `ifreload -a`.
- Restore the saved file immediately if management, DNS, route, MTU or VLAN isolation changes unexpectedly.
command
Configure official repositories and apply a controlled update
Select the Proxmox enterprise repository when the node has a subscription or the official no-subscription repository only when the documented support/risk decision permits it. Match Debian 13 Trixie and PVE 9 suites, remove obsolete or duplicate entries, update indexes, review the exact upgrade plan, back up configuration and guests, then perform the full upgrade in a maintenance window.
Why this step matters
Proxmox updates span kernel, QEMU, ZFS, management and security. Repository provenance and a reviewed full dependency transaction are essential; partial `apt upgrade` or mixed suites can strand the platform.
What to understand
Never enable both enterprise and no-subscription for the same suite, and do not accept unsigned third-party repositories on a hypervisor.
Read Proxmox roadmap/release notes and known issues; evacuate or shut down workloads and confirm a boot/recovery path before kernel/ZFS changes.
After reboot validate pool, bridge, firewall, certificates, PVE services, guest agents and backups before the next node/wave.
System changes
- Refreshes official package metadata and installs current supported PVE 9.2/Debian security and feature packages; a later controlled reboot may activate kernel changes.
Syntax explained
apt full-upgrade- Allows dependency additions/removals required for the supported Proxmox package set; review its plan first.
pveversion -v- Lists Proxmox component package versions before and after the transaction.
grep -RhsE '^[^#].*deb|^Types:|^URIs:|^Suites:|^Components:' /etc/apt/sources.list /etc/apt/sources.list.d/; apt update; apt list --upgradable; pveversion -v; apt full-upgrade; systemctl --failed; pveversion -vHit:1 http://deb.debian.org/debian trixie InRelease Hit:2 https://enterprise.proxmox.com/debian/pve trixie InRelease All packages are up to date. proxmox-ve: 9.2.1 (running kernel: 7.0.4-1-pve) pve-manager: 9.2.2 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 0 loaded units listed.
Checkpoint: Checkpoint: Configure official repositories and apply a controlled update
Continue whenOnly approved official suites, signed metadata, reviewed transaction, no held/broken packages, no failed units, current PVE component versions and a tested reboot plan.
Stop whenMixed release/repository, unsigned metadata, unexpected removal, third-party kernel module conflict, no guest backup, or console/reboot recovery missing.
If this step fails
APT update reports mixed or unsigned Proxmox repositories.
Likely causeEnterprise and no-subscription suites, Debian release names, third-party repositories, keys, or subscription state are inconsistent.
grep -RhsE '^[^#].*deb|^Types:|^URIs:|^Suites:' /etc/apt/sources.list /etc/apt/sources.list.d/apt updatepveversion -v
ResolutionDisable unapproved sources, select the official repository matching subscription and Proxmox VE 9/Debian 13, then update indexes without accepting unauthenticated packages.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop before full-upgrade if the plan removes `proxmox-ve`, changes release suite unexpectedly, or backup/console/maintenance capacity is unavailable.
- Do not continue rollout after any failed service, storage, network, certificate, guest or backup check.
verification
Restrict management, delegate roles, enable MFA, firewall, and trusted TLS
Create named administrative users and least-privilege groups/roles through Proxmox's supported UI/API, enroll TOTP or WebAuthn MFA, preserve a vaulted break-glass root path, restrict 8006/SSH/BMC to management sources with PVE/datacenter and upstream firewalls, and deploy an ACME or approved certificate. Test an allowed operator and denied non-admin from separate clients.
Why this step matters
The hypervisor can read guest disks, inject console input and alter networks. Password-only broad admin exposed on general networks is incompatible with that impact.
What to understand
Avoid scripting user passwords or TOTP seeds. Enroll through protected interactive UI and store break-glass credentials in an audited vault.
PVE firewall changes can lock out the node; keep BMC console and test source-specific rules before enabling datacenter/node defaults.
Certificate trust must be verified from an external admin client using the FQDN; a valid certificate on a public interface is not a firewall.
System changes
- Creates delegated identities/MFA, management firewall policy and trusted certificate through interactive protected workflows.
Syntax explained
pveum acl list- Shows effective Proxmox path/role assignments for audit.
pve-firewall status- Reports compilation/runtime status; packet-path tests remain required.
pvenode cert info- Displays active certificate metadata without private key.
pveum user list; pveum group list; pveum acl list; pve-firewall status; nft list ruleset; pvenode cert info; ss -lntp | grep -E ':22|:8006'userid enable expire firstname lastname
ops@example 1 0 Ops Team
breakglass@pam 1 0
GROUPS
groupid comment
PVEAuditors Read-only operations
Status: enabled/running
LISTEN 0 4096 10.20.0.11:8006 users:(("pveproxy",pid=1428,fd=6))
Subject: CN=pve01.example.net
Issuer: CN=Example Internal ACME CACheckpoint: Checkpoint: Restrict management, delegate roles, enable MFA, firewall, and trusted TLS
Continue whenNamed MFA admin succeeds from management network; viewer cannot mutate; untrusted source cannot reach 22/8006/BMC; break-glass and TLS hostname/chain work.
Stop whenShared root used routinely, MFA unavailable, broad role assignment, public management exposure, firewall errors, or TLS validation requires bypass.
If this step fails
The Proxmox web/API certificate is untrusted or names the wrong host.
Likely causeDNS, ACME validation, certificate chain, proxying, hostname, or renewal failed, or an administrator accepted the default fingerprint without controlled bootstrap.
pvenode cert infoopenssl s_client -connect {{managementFqdn}}:8006 -servername {{managementFqdn}} -showcerts </dev/nulljournalctl -u pveproxy --since '-1 hour' --no-pager
ResolutionRestore canonical DNS/time, renew/import through Proxmox-supported certificate workflow, verify chain/hostname externally, and do not disable TLS checks.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop when hardware, identity, DNS, time, storage, network, certificate, backup, version, or ownership evidence differs from the approved plan.
- Stop when independent console/recovery, current backup, restore capacity, or a named rollback owner is unavailable.
verification
Add independent encrypted backup storage and validate custody
Deploy or select an off-host Proxmox Backup Server with separate storage and offsite sync, verify its TLS fingerprint through an independent channel, create a least-privilege backup identity/API token without placing it in argv, store encryption keys/recovery material outside PVE, and add the PBS datastore through the protected UI. Validate status, namespace, content type, capacity and retention ownership.
Why this step matters
A backup on the same pool/host fails with the host. PBS adds deduplication, verification, client-side encryption and offsite sync, but only when identity, fingerprint, keys, capacity and retention are independently controlled.
What to understand
Do not use the PBS root user or embed token secrets in shell history. Enter the token through the UI/secret workflow and restrict datastore/namespace privileges.
If client-side encryption is enabled, loss of the encryption key makes backups unrecoverable; store and test key recovery outside PVE and PBS.
PBS verification checks chunks, while VM/application restore tests prove semantic recoverability.
System changes
- Adds an off-host PBS storage definition and protected credential through Proxmox UI/API; no guest backup yet.
Syntax explained
fingerprint- Pins the PBS TLS certificate during controlled bootstrap; compare independently.
content backup- Restricts this storage definition to backup archives.
least-privilege token- Limits the PVE node to required datastore/namespace operations and supports independent revocation.
Values stay on this page and are never sent or saved.
pvesm status; pvesm list {{backupStorage}} --vmid {{testVmId}}; grep -A12 '^pbs: {{backupStorage}}' /etc/pve/storage.cfg | sed -E 's/(password|token|key).*/\1 [REDACTED]/I'Name Type Status Total Used Available %
backup-pbs pbs active 7.28 TB 2.10 TB 5.18 TB 28.84%
Volid Format Type Size
backup-pbs:backup/vm/100/2026-07-28T01:00:02Z pbs-vm backup 18.4GiB
pbs: backup-pbs
server pbs01.example.net
datastore production
content backup
fingerprint 7a:0b:...:e4
username pve-backup@pbs!pve01Checkpoint: Checkpoint: Add independent encrypted backup storage and validate custody
Continue whenPBS active with verified fingerprint, restricted token, encryption key recoverable separately, capacity/retention/offsite sync monitored and existing archive listing works.
Stop whenPBS shares host/storage failure domain, fingerprint/key custody unknown, root credential used, storage nearly full, or offsite/retention owner missing.
If this step fails
A vzdump job completes with warnings or no usable archive.
Likely causeGuest agent freeze, storage capacity, PBS connectivity/fingerprint, snapshot support, lock, excluded disk, or retention policy caused a partial result.
journalctl -u pvedaemon --since '-2 hours' --no-pagerpvesm statuspvesm list {{backupStorage}}qm config {{testVmId}}
ResolutionTreat warning/partial as failed, correct guest/storage/transport scope, run a new backup, and prove it through isolated restore.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop when hardware, identity, DNS, time, storage, network, certificate, backup, version, or ownership evidence differs from the approved plan.
- Stop when independent console/recovery, current backup, restore capacity, or a named rollback owner is unavailable.
command
Create and run an application-aware scheduled guest backup
Install and verify the QEMU guest agent where supported, quiesce or use application-native backup for transactional workloads, then create a scheduled snapshot-mode job with zstd compression, protected PBS storage, notification and retention policy. Run one named canary backup and treat every warning as failure until explained.
Why this step matters
A schedule without a successful representative run can hide agent, lock, storage, bandwidth, notification, excluded-disk and application-consistency defects.
What to understand
Snapshot mode is Proxmox backup terminology and is not proof that every database/application flushed coherently; use its documented backup hooks or in-guest exports.
Inspect VM configuration for disks marked `backup=0` and record every intentional exclusion with its separate recovery method.
Retention must exist on PBS and satisfy ransomware, operator error, legal and capacity requirements; keep immutable/offsite controls where required.
System changes
- Creates a scheduled backup job and writes one canary VM archive to PBS.
Syntax explained
--mode snapshot- Backs up a running guest using storage/QEMU snapshot mechanisms supported by Proxmox.
--compress zstd- Uses efficient zstd compression for archive transport/storage.
--vmid- Scopes the initial job to the reviewed canary rather than an unbounded all-guests rollout.
Values stay on this page and are never sent or saved.
qm agent {{testVmId}} ping; pvesh create /cluster/backup --storage {{backupStorage}} --vmid {{testVmId}} --mode snapshot --compress zstd --schedule '{{backupSchedule}}' --enabled 1; vzdump {{testVmId}} --storage {{backupStorage}} --mode snapshot --compress zstd; pvesm list {{backupStorage}} --vmid {{testVmId}}UPID:pve01:00004F21:01A3B611:66A8A1F2:vzdump:100:root@pam: INFO: Starting Backup of VM 100 (qemu) INFO: backup mode: snapshot INFO: creating Proxmox Backup Server archive 'vm/100/2026-07-28T14:01:02Z' INFO: 100% (18.4 GiB of 18.4 GiB) in 3m 42s INFO: Finished Backup of VM 100 (00:03:47) INFO: Backup job finished successfully
Checkpoint: Checkpoint: Create and run an application-aware scheduled guest backup
Continue whenGuest agent/application gate passes, one complete archive includes all intended disks/config, duration fits window, notification works, PBS verify/retention/offsite sync are current.
Stop whenAny warning, excluded critical disk, failed freeze/export, capacity/bandwidth breach, notification failure or missing encryption key recovery.
If this step fails
A vzdump job completes with warnings or no usable archive.
Likely causeGuest agent freeze, storage capacity, PBS connectivity/fingerprint, snapshot support, lock, excluded disk, or retention policy caused a partial result.
journalctl -u pvedaemon --since '-2 hours' --no-pagerpvesm statuspvesm list {{backupStorage}}qm config {{testVmId}}
ResolutionTreat warning/partial as failed, correct guest/storage/transport scope, run a new backup, and prove it through isolated restore.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop when hardware, identity, DNS, time, storage, network, certificate, backup, version, or ownership evidence differs from the approved plan.
- Stop when independent console/recovery, current backup, restore capacity, or a named rollback owner is unavailable.
verification
Restore the guest to isolated storage and network
Select an exact verified PBS restore point, allocate an unused restore VMID, restore to a separate target storage with a unique MAC/identity, attach only to an isolated bridge, boot it, and run guest filesystem plus application integrity tests. Measure achieved RPO/RTO and destroy the drill copy only after evidence approval.
Why this step matters
Only a full restore proves archive, configuration, disks, encryption keys, target capacity and application state. Isolation prevents duplicate IP, hostname, domain, cluster, database or client synchronization.
What to understand
Verify the selected volume ID, source VMID, timestamp and restore VMID with two operators; never restore over production.
Use an isolated bridge with no route to production and disable automatic startup until identity changes are understood.
Inside the guest, validate filesystem, service dependencies, database/application transactions, authentication and expected records—not just boot.
System changes
- Creates and starts a separate restored VM on isolated storage/network with unique virtual MAC.
Syntax explained
--unique 1- Generates unique identifiers such as MAC where supported to reduce collision.
--storage- Targets dedicated restore capacity instead of overwriting production disks.
isolatedBridge- Prevents restored identity and application from contacting production.
Values stay on this page and are never sent or saved.
pvesm list {{backupStorage}} --vmid {{testVmId}}; qmrestore {{backupVolumeId}} {{restoreVmId}} --storage {{restoreStorage}} --unique 1; qm set {{restoreVmId}} --net0 virtio,bridge={{isolatedBridge}},firewall=1; qm config {{restoreVmId}}; qm start {{restoreVmId}}; qm status {{restoreVmId}}restore vma archive: zstd -q -d -c ... progress 100% (read 19756849561 bytes, duration 224 sec) new volume ID is 'restore-zfs:vm-9100-disk-0' restore successful net0: virtio=BC:24:11:90:10:01,bridge=vmbr99,firewall=1 status: running
Checkpoint: Checkpoint: Restore the guest to isolated storage and network
Continue whenExact restore point produces a bootable isolated guest with all disks/config; filesystem/app integrity and expected records pass within RPO/RTO; production unchanged.
Stop whenTarget VMID/storage is not empty, bridge routes to production, key/archive missing, disk omitted, guest identity collides, or application check fails.
If this step fails
Backup verification succeeds but the restored guest does not boot or data is inconsistent.
Likely causeThe wrong restore point, excluded disk, application-inconsistent snapshot, firmware/storage mapping, or external state was not captured.
pvesm list {{backupStorage}} --vmid {{testVmId}}qm config {{restoreVmId}}qm status {{restoreVmId}}Review guest and application integrity logs on the isolated network.
ResolutionKeep production unchanged, preserve the failed restore, correct backup/application consistency and component scope, then repeat a clean isolated restore.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Never use a production VMID or production-connected bridge for the first restore.
- Keep the failed restore and backup source unchanged for diagnosis if any component or application check differs.
verification
Rehearse bare-metal host rebuild and guest recovery
Protect the versioned build record, interfaces/hosts, storage definitions, firewall rules, user/role inventory, certificates and required private recovery material with correct access; preserve the pmxcfs database only as documented recovery evidence, not a blind file overlay. On spare hardware or a destructive lab target, reinstall the verified ISO, patch, rebuild network/storage/access/PBS from reviewed configuration, then restore one guest and application.
Why this step matters
Guest backups do not recreate host identity, bridge, storage mappings, firewall, access or PBS trust. A spare-host rebuild proves the human runbook and identifies secrets/configuration that were trapped on the failed node.
What to understand
`/etc/pve` is pmxcfs-managed; do not blindly untar it over a running cluster/filesystem. Recreate through supported interfaces or use documented disaster recovery with services stopped and exact version context.
The configuration archive can contain hashes, token references, certificates and sensitive topology; encrypt and restrict it, and store decryption keys separately.
A real drill ends with one isolated restored guest and application acceptance, not merely a login to port 8006.
System changes
- Creates a protected host-configuration archive and rebuilds separate spare/lab hardware during the drill; production host remains unchanged.
Syntax explained
--xattrs --acls- Preserves extended attributes and ACLs in the protected configuration archive.
config.db- Captures pmxcfs state for documented recovery analysis; it is not copied live into a new installation casually.
Values stay on this page and are never sent or saved.
tar --xattrs --acls -czf {{hostConfigArchive}} /etc/network/interfaces /etc/hosts /etc/pve/storage.cfg /etc/pve/firewall /var/lib/pve-cluster/config.db; sha256sum {{hostConfigArchive}}; pveversion -v; pvesm status; pve-firewall status; pveum user listtar: Removing leading `/' from member names 4b8f7a6d4c6d8d19beef44c301d72c2d131c9e1b1aaf78357a4c338e05c80a62 /root/recovery/pve01-config-20260728.tgz proxmox-ve: 9.2-1 backup-pbs pbs active Status: enabled/running userid enable ops@example 1
Checkpoint: Checkpoint: Rehearse bare-metal host rebuild and guest recovery
Continue whenSpare host reaches reviewed PVE 9.2 patch, network/storage/TLS/MFA/firewall/PBS work, guest restores isolated, application passes and measured RTO meets target.
Stop whenArchive/key missing, target hardware/disks ambiguous, configuration version incompatible, pmxcfs would be overwritten live, or restored guest could collide with production.
If this step fails
A bare-metal recovery has guests but lacks correct host network, storage, firewall, users, or keys.
Likely causeOnly guest archives were protected; host-specific configuration, inventory, encryption material, PBS fingerprint, and recovery instructions were absent or stale.
Compare `/etc/network/interfaces`, `/etc/pve/storage.cfg`, firewall and user/role exports with the protected build record.pvesm statuspve-firewall statuspveum user list
ResolutionKeep recovered guests isolated, rebuild the host from approved inventory and protected configuration/keys, validate each layer, then restore guests and rotate uncertain credentials.
Security notes
- Use named, least-privilege administrative identities over a protected management path. Keep passwords, API tokens, private keys, backup encryption keys, recovery material, and user data out of command arguments, logs, screenshots, tickets, and this guide.
- Preserve an exact before-state and validate the effective result from a real guest, client, or restore target. A successful local command is not end-to-end proof.
Alternatives
- Rehearse this step on an isolated canary with production-shaped hardware, network, storage, identity, data, monitoring, and recovery before production.
Stop conditions
- Stop when hardware, identity, DNS, time, storage, network, certificate, backup, version, or ownership evidence differs from the approved plan.
- Stop when independent console/recovery, current backup, restore capacity, or a named rollback owner is unavailable.
Finish line
Verification checklist
pveversion -v; zpool status -v {{zpoolName}}; zpool list {{zpoolName}}; systemctl --failedPVE 9.2 current, ZFS ONLINE zero errors with reserve, no failed units.ip -br address; bridge vlan show; pve-firewall status; pvenode cert infoCanonical management remains restricted/trusted and only intended VLANs pass.qm config {{restoreVmId}}; qm status {{restoreVmId}}; pvesm list {{backupStorage}} --vmid {{testVmId}}Exact PBS point restores unique isolated guest and application integrity meets RPO/RTO.pveversion -v; pvesm status; pve-firewall status; pveum user listSpare host reconstructs supported version, network/storage/access/PBS and restores one guest/application.Recovery guidance
Common problems and safe checks
The Proxmox installer cannot see the intended system disks.
Likely causeController mode or firmware is unsupported, disks are behind a hardware RAID abstraction, NVMe firmware is stale, or the selected HBA does not expose devices as planned.
Inspect firmware/BMC storage inventory and controller mode.lsblk -e7 -o NAME,SIZE,MODEL,SERIAL,TYPElspci -nnk | grep -A3 -Ei 'raid|sata|sas|nvme'
ResolutionStop installation, correct the vendor-supported controller/HBA and firmware design, then re-identify every disk by model/serial before allowing any erase.
The installed host boots but reports no virtualization extensions.
Likely causeIntel VT-x/AMD-V, VT-d/IOMMU, NX, or nested virtualization is disabled or unsupported by firmware/platform.
egrep -c '(vmx|svm)' /proc/cpuinfodmesg | grep -Ei 'kvm|iommu|dmar'pveversion -v
ResolutionEnable the exact vendor firmware features, update supported firmware if required, reboot, and prove KVM/IOMMU health before creating guests.
The host becomes unreachable after applying bridge networking.
Likely causeThe physical interface name, VLAN-aware setting, address/gateway, bond, switch trunk, MTU, or management path differs from the reviewed design.
ip -br linkip -br addressip routecat /etc/network/interfacesbridge vlan show
ResolutionUse BMC/local console, restore the versioned interfaces file with `ifreload -a`, then correct the physical switch and host design before retrying.
Guests attach to vmbr0 but cannot reach the intended VLAN.
Likely causeBridge VLAN filtering, guest tag, trunk/native VLAN, firewall, MTU, duplicate address, or upstream port policy is wrong.
qm config {{testVmId}}bridge vlan showip -d link show vmbr0tcpdump -eni {{physicalNic}} vlan {{guestVlan}}
ResolutionReconcile guest tag, VLAN-aware bridge and upstream trunk; change only the mismatching layer and retest an allowed plus denied path.
ZFS pool is DEGRADED, FAULTED, or resilvering unexpectedly.
Likely causeA disk, cable, backplane, controller, ashift choice, or previous replacement has failed or the wrong device was selected.
zpool status -v {{zpoolName}}zpool events -v | tail -n 100smartctl -x {{diskDevice}}ls -l /dev/disk/by-id/
ResolutionStop workload growth, identify the exact by-id device, preserve evidence and backups, follow the reviewed replace/resilver procedure, and do not clear errors before understanding them.
ZFS pool usage grows until guests pause or writes fail.
Likely causeSnapshots, thin provisioning, replication, backup fleecing, logs, or unbounded guest allocations consumed reserve and alerts were absent.
zpool listzfs list -o name,used,available,refer,mountpointzfs list -t snapshot -o name,used,creation -s creationpvesm status
ResolutionStop new provisioning/snapshots, protect running guests, add approved capacity or expire data through policy, and preserve free-space reserve instead of deleting unknown snapshots.
APT update reports mixed or unsigned Proxmox repositories.
Likely causeEnterprise and no-subscription suites, Debian release names, third-party repositories, keys, or subscription state are inconsistent.
grep -RhsE '^[^#].*deb|^Types:|^URIs:|^Suites:' /etc/apt/sources.list /etc/apt/sources.list.d/apt updatepveversion -v
ResolutionDisable unapproved sources, select the official repository matching subscription and Proxmox VE 9/Debian 13, then update indexes without accepting unauthenticated packages.
A package update leaves services unhealthy or the node needs an unexpected reboot.
Likely causeKernel/QEMU/ZFS/pve-manager dependencies changed, third-party modules are incompatible, services failed, or maintenance capacity was not prepared.
pveversion -vsystemctl --failedjournalctl -p err -b --no-pagerproxmox-boot-tool statusneedrestart -r l 2>/dev/null || true
ResolutionFreeze rollout, preserve package/log evidence, use console, restore a supported boot entry or package state where documented, and validate storage/network/guests before reopening.
A vzdump job completes with warnings or no usable archive.
Likely causeGuest agent freeze, storage capacity, PBS connectivity/fingerprint, snapshot support, lock, excluded disk, or retention policy caused a partial result.
journalctl -u pvedaemon --since '-2 hours' --no-pagerpvesm statuspvesm list {{backupStorage}}qm config {{testVmId}}
ResolutionTreat warning/partial as failed, correct guest/storage/transport scope, run a new backup, and prove it through isolated restore.
Backup verification succeeds but the restored guest does not boot or data is inconsistent.
Likely causeThe wrong restore point, excluded disk, application-inconsistent snapshot, firmware/storage mapping, or external state was not captured.
pvesm list {{backupStorage}} --vmid {{testVmId}}qm config {{restoreVmId}}qm status {{restoreVmId}}Review guest and application integrity logs on the isolated network.
ResolutionKeep production unchanged, preserve the failed restore, correct backup/application consistency and component scope, then repeat a clean isolated restore.
The Proxmox web/API certificate is untrusted or names the wrong host.
Likely causeDNS, ACME validation, certificate chain, proxying, hostname, or renewal failed, or an administrator accepted the default fingerprint without controlled bootstrap.
pvenode cert infoopenssl s_client -connect {{managementFqdn}}:8006 -servername {{managementFqdn}} -showcerts </dev/nulljournalctl -u pveproxy --since '-1 hour' --no-pager
ResolutionRestore canonical DNS/time, renew/import through Proxmox-supported certificate workflow, verify chain/hostname externally, and do not disable TLS checks.
A bare-metal recovery has guests but lacks correct host network, storage, firewall, users, or keys.
Likely causeOnly guest archives were protected; host-specific configuration, inventory, encryption material, PBS fingerprint, and recovery instructions were absent or stale.
Compare `/etc/network/interfaces`, `/etc/pve/storage.cfg`, firewall and user/role exports with the protected build record.pvesm statuspve-firewall statuspveum user list
ResolutionKeep recovered guests isolated, rebuild the host from approved inventory and protected configuration/keys, validate each layer, then restore guests and rotate uncertain credentials.
Reference
Frequently asked questions
Does a ZFS mirror replace backup?
No. It protects some disk failures but shares the host, pool and administrative failure domain. Use off-host/offsite PBS and prove restore.
Can a successful PBS verify replace restore?
No. Verification checks stored chunks/indexes. Only an isolated boot and application integrity test proves the selected guest is recoverable.
Can `/etc/pve` simply be untarred onto a live rebuild?
No. It is managed by pmxcfs. Recreate through supported interfaces or follow exact documented disaster recovery with services/version controlled.
Recovery
Rollback
Rollback only the current reviewed layer: restore bridge configuration through BMC, return to the supported previous boot/package state, remove an empty new storage definition, or recover guests from verified PBS. Never overwrite ambiguous disks, pools, pmxcfs or production VMIDs.
- Freeze guest changes and preserve hardware, pool, network, package, firewall, backup and event evidence.
- For bridge failure, restore the saved `/etc/network/interfaces` from console and apply with supported ifupdown2.
- For update failure, boot a known supported entry or use documented package recovery; validate pool/network/PVE before guests.
- For host loss, reinstall verified ISO on confirmed replacement disks, rebuild host configuration through supported interfaces, connect PBS and restore to isolated VMIDs first.
- Rotate any uncertain API token, certificate or encryption/recovery credential after incident recovery.
Evidence