Learn Proxmox Backup Server - Core Concepts & Key Architecture

#Introduction

After understanding PBS's history and motivation in episode 1, now we break down how it works from the inside. The architecture determines everything: why dedup is so effective, why restore can be instant, and why backups stay consistent even while VMs run continuously. In episode 2 we trace PBS's anatomy — from the datastore on storage to the chunks spread inside it.

Imagine PBS like a library with a digital catalog system: the datastore is the building, chunks are the books (split per page), and backup groups are named shelves per title. Whenever a book has pages identical to existing collection, the library just records a reference, not copying new pages.

#Architecture: Datastore, Chunking, and Backup Groups

#Datastore: The Home of All Chunks

A datastore is a folder (path) on PBS storage where all backup data lives. All snapshots — from all VMs, CTs, and hosts — share the same chunk space. This is why cross-VM dedup becomes possible: a chunk from VM A's backup identical to VM B's only needs to be stored once.

proxmox-backup-manager datastore list

proxmox-backup-manager datastore list shows the name, path, and status of all datastores on the server. One server can have many datastores, for example separated per department or priority level — discussed in episode 18.

#Content-Defined Chunking: The Key to Dedup

PBS splits data into chunks using content-defined chunking (CDC): chunk boundaries are determined by the data content (via a rolling hash), not by fixed offsets. Why does this matter? Because if you insert data in the middle of a file, the chunk boundaries follow the content, so the unchanged parts still produce the same chunks — and can still be deduplicated. This is what makes PBS dedup effective even for snapshots that change only slightly.

Each chunk is identified by the checksum of its content. Identical content means an identical checksum, which means it only needs to be stored once.

ls /var/lib/proxmox-backup/datastore/store1

The chunk folder contains compressed chunk files, organized by checksum. Never modify the contents of this folder manually — manipulating it without the API will corrupt the repository integrity.

#Backup Groups and Snapshots per VM/CT/Host

Data is organized into backup groups: one group represents one source (VM ID, CT ID, or hostname). Within a group, each backup time becomes a snapshot with the format {group}/{snapshot-timestamp}:

vm/100/2026-08-13T02:00:04Z   → group "vm/100", snapshot 2026-08-13T02:00:04Z
host/web01/2026-08-12T22:15:01Z
ct/300/2026-08-13T02:10:33Z

A group contains many snapshots from different times. Retention (episode 8) decides which snapshots are kept, and GC (episode 6) cleans up chunks that are no longer referenced.

#Key PBS Components

#The proxmox-backup Server

The core of the service is the proxmox-backup daemon, which provides the REST API, manages datastores, executes jobs (backup, verify, GC, sync, prune), and handles client connections. This service runs as proxmox-backup.service and must be active before all features work.

systemctl status proxmox-backup --no-pager

#Web UI on Port 8007

PBS is managed through the HTTPS web UI on port 8007 (https://IP-PBS:8007). From here you create datastores, users, ACLs, job schedules (backup schedule in PVE, verify, GC, sync, prune), monitor task logs, and perform file restores. Every web UI operation essentially calls the same API.

#The proxmox-backup-client CLI

On the client side (PVE, Linux hosts, or containers), the proxmox-backup-client command performs file/host backup and restore. PVE itself calls this tool behind the scenes when running VM/CT backups.

proxmox-backup-client backup etc.pxar:/etc \
  --repository backup@pbs@10.0.1.10:store1

#The proxmox-backup-manager CLI

On the server side, proxmox-backup-manager manages datastores, users, ACLs, tokens, and jobs from the terminal. Many operations you would normally click in the web UI can also be executed through this command — and we will use it in almost every episode.

#API and PVE Datacenter Integration

Every PBS operation is exposed through the REST API (on port 8007). This API is used by the web UI, proxmox-backup-client, proxmox-backup-manager, and the Proxmox VE datacenter integration. When PVE is added to PBS as a storage, PVE stores the PBS certificate fingerprint and uses the API with user/token authentication — a flow we practice in episode 4.

#The Backup Flow Conceptually

The logical sequence when a VM backup is run from Proxmox VE:

1. PVE calls the PBS API with the credentials of the registered storage.
2. The VM disk data is read (according to mode: snapshot/suspend/stop) and split into chunks.
3. Chunks already in the datastore are recognized by checksum and skipped (dedup).
4. New chunks are sent, compressed, and stored; snapshot metadata is recorded.
5. The new snapshot appears in the backup group with status complete.

#Closing

Key takeaways:

• A datastore is a folder where all chunks are stored; one server can have many datastores.
• Content-defined chunking (CDC) makes dedup effective across backups and VMs.
• Backup groups group snapshots per VM/CT/host; snapshots use the group/timestamp format.
• proxmox-backup is the core daemon; the web UI on port 8007 is its main interface.
• proxmox-backup-client for client-side backup, proxmox-backup-manager for server administration.
• The REST API on 8007 connects the web UI, CLI, and PVE datacenter integration.

In the next episode, episode 3, we will install and configure PBS — from the ISO installer or the apt repository, disk and ZFS selection, network configuration, to creating the first datastore with GC and verify schedules, plus users with the PAM/LDAP/Proxmox VE realms. Time to build your first server!