Proxmox VE and Proxmox Backup Server

Proxmox VE is straightforward to install, but a production virtualization platform is a design exercise: cluster boundaries, quorum, storage, network paths, backup independence, maintenance access, and recovery behavior all need to be decided before the first customer VM is created.

Think in Failure Domains

A Proxmox “datacenter” in the interface is not automatically a disaster-recovery design. List the physical dependencies behind every node:

• Facility, room, rack, power circuit, and UPS
• Top-of-rack switch and upstream path
• Management, cluster, storage, and guest networks
• Local disks, shared storage, or distributed storage
• Backup server and backup datastore
• Out-of-band controller and console path

                    Public / customer networks
                              |
                      Redundant switching
                         /           \
                    PVE-01           PVE-02
                       \               /
                        \  Cluster    /
                         \ network   /
                          \         /
                        Shared or replicated
                              storage
                                 |
                         Proxmox Backup Server
                                 |
                       Off-site sync / second copy
    

The diagram is only resilient if the lines represent genuinely independent paths. Two switches connected to one upstream, two power supplies on one circuit, or backups stored in the same rack may provide convenience without protecting against the failure you care about.

Clusters, Quorum, and Administrative Reality

A cluster centralizes configuration and enables migrations and high-availability features, but it also introduces quorum and cluster-network dependencies. Do not create a cluster merely to make multiple nodes appear in one interface.

Good reasons to cluster

• Guests need to migrate between nodes.
• Shared configuration and coordinated storage are operationally useful.
• The team understands quorum, fencing, and recovery from node or network loss.
• The cluster network is stable, low-latency, and separated from avoidable congestion.

Reasons to keep systems independent

• The nodes are in physically distant sites with unreliable or high-latency connectivity.
• Each node hosts independent workloads that do not require migration.
• Joining them would create one administrative failure domain.
• The goal is only a single pane of glass rather than cluster behavior.

Three-node thinking

Odd-numbered voting arrangements are easier to reason about than two equal nodes that cannot determine which side is authoritative after a partition. In smaller environments, a quorum device may be appropriate, but it should be treated as a real dependency with its own availability and security requirements.

Storage Design

The best storage design depends on workload, recovery objectives, budget, and operator experience. There is no universal answer between local ZFS, NFS, iSCSI, Ceph, and other supported backends.

Storage questions to answer before production

• What happens when the storage reaches 100 percent?
• How are disk and controller failures detected?
• Can a guest be restored to a different storage type?
• How long will a full restore take at realistic throughput?
• Does migration traffic compete with customer or backup traffic?
• Is storage shared between clusters that cannot coordinate locking?
• How are snapshots aged and removed?

Thin provisioning needs a hard ceiling

Thin provisioning allows logical allocations to exceed physical use. That is useful until growth from multiple guests converges at once. Alert on both free space and rate of change, and maintain enough reserve to complete emergency migrations, snapshots, or restores.

Separate Traffic by Purpose

A small cluster may use fewer physical interfaces, but traffic should still be logically designed. Common network purposes include:

Example Linux bridge layout

auto lo
iface lo inet loopback

iface eno1 inet manual
iface eno2 inet manual

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 10.20.0.11/24
    gateway 10.20.0.1
    bridge-ports bond0.20
    bridge-stp off
    bridge-fd 0

# VLAN-aware guest trunk
auto vmbr1
iface vmbr1 inet manual
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 100-399
    

This is only an example. Bonding mode, switch configuration, VLAN tagging, and management addressing must match the actual design. Never apply a remote network change without verified out-of-band access.

Proxmox Backup Server

Proxmox Backup Server is more than a place to send backup files. It provides datastores, deduplication, verification jobs, pruning, garbage collection, optional client-side encryption, and synchronization between backup servers.

A practical backup architecture

PVE cluster A ----\
                   >---- PBS-A datastore ---- sync ---- PBS-B at another site
PVE cluster B ----/              |
                                 +---- verification jobs
                                 +---- prune policy
                                 +---- garbage collection
                                 +---- restore tests
    

Datastore operations

• Prune: Selects backup snapshots for removal according to retention rules.
• Garbage collection: Reclaims unreferenced chunks after pruning.
• Verification: Reads and checks backup data so corruption is discovered before a restore is needed.
• Sync: Copies backup groups or snapshots to another Proxmox Backup Server.

Encryption-key discipline

Client-side encryption can protect backup content from the backup-server operator, but it changes recovery. Store encryption keys and recovery information outside the systems being backed up. Test a restore from a clean administrative workstation using only the documented recovery materials.

Production Operations

Before maintenance

• Cluster and storage health are normal.
• Recent backups exist and critical restores have been tested.
• Out-of-band access works.
• There is enough capacity on remaining nodes for evacuation.
• Customer-impacting workloads and maintenance restrictions are identified.
• The rollback path and package repository state are documented.

Useful platform checks

# Cluster status
pvecm status

# Node and guest overview
pvesh get /cluster/resources --type vm

# Storage status
pvesm status

# ZFS pool health
zpool status
zpool list

# Failed systemd units
systemctl --failed

# Recent task history is also available in the web interface and API.
    

Do not update every node simultaneously

Use a rolling pattern: validate health, evacuate or stop workloads according to the plan, update one node, reboot if required, validate storage and networking, return workloads, and only then continue. Keep at least one known-good node until the change is proven.

Failure Scenarios to Rehearse

Official References

• Proxmox VE Administration Guide
• Proxmox Backup Server Documentation
• Proxmox VE Storage
• Proxmox Backup Server Maintenance Tasks

Related: Build the wider backup and disaster-recovery plan and design out-of-band access.