"The disk died and we lost everything."

You get a message on a Saturday morning: nobody in the neighborhood can connect. You log into the Proxmox web interface --- or try to. The page does not load. You drive to the community center, open the cabinet, and find the mini PC's disk activity light dark. The SSD that held your Proxmox host is dead. The DNS container, the DHCP server, the Nextcloud instance with shared documents, the Zabbix monitoring setup you spent weeks tuning --- all of it lived on that one drive, and all of it is gone.

The human cost hits immediately. Users lose internet access because there is no DNS or DHCP. The shared documents that neighbors uploaded to Nextcloud --- meeting notes, grant applications, a spreadsheet tracking who paid their monthly contribution --- vanish. Worst of all, you have no record of how the system was configured. The firewall rules, the VLAN assignments, the static leases, the backup jobs you were about to set up --- none of it was written down in a way that lets you rebuild. You are not recovering from an outage. You are starting from scratch, weeks of work erased in a single hardware failure.

This is not a rare scenario. Consumer-grade SSDs and hard drives fail. Power surges happen, especially in areas with unstable electricity. Volunteers accidentally delete the wrong container. A bad firmware update corrupts the filesystem. The question is never if you will lose data, but when --- and whether you will be able to get it back.

The standard approach is the 3-2-1 rule: keep at least 3 copies of your data, on 2 different types of storage, with 1 copy off-site. For a community network running Proxmox, that translates to something concrete. Your VMs and containers live on the host's internal disk --- that is copy one. A backup job writes snapshots to a second disk, either inside the same machine or on a separate device on the local network --- that is copy two, on different storage. And you replicate those backups to another building or a remote server --- that is copy three, off-site. If any single point fails, you still have your data.

Proxmox Backup Server (PBS) is built exactly for this workflow. It is a dedicated backup system designed to integrate with Proxmox VE. PBS supports incremental backups --- after the first full snapshot, only the blocks that changed are transferred, which means nightly backups of an entire host finish in minutes instead of hours. It handles deduplication automatically, so identical data blocks across different VMs and containers are stored only once. On a community network with limited disk space, this matters: ten containers that share the same Debian base image do not consume ten times the storage in backups. PBS also provides encryption and integrity verification, so you can trust that your backups are both private and uncorrupted when you need them.

You do not need a dedicated server for PBS. For a small deployment, running PBS as an LXC container on a second machine --- or even on the same Proxmox host but writing to a separate physical disk --- gives you local backup coverage. What matters is that the backup storage is physically separate from the data it protects. A backup sitting on the same disk as the original is not a backup at all. If you have a second node in another building, PBS can replicate to it automatically, covering the off-site leg of the 3-2-1 rule without any cloud dependency.

The real value shows up on the day something breaks. With PBS integrated into the Proxmox web interface, restoring a container or VM to any previous snapshot takes a few clicks. You pick the backup point, hit restore, and the service is back --- configuration, data, and all. That Saturday morning with the dead disk becomes an inconvenience instead of a catastrophe: you replace the drive, reinstall Proxmox, point it at your PBS datastore, and restore everything.