When people talk about Proxmox Backup Server (PBS), they almost always mean backing up Proxmox VE virtual machines. That is exactly how I started too.

But over time, I realized that together with Proxmox Backup Client it can do much more.

The client can be installed on almost any modern Linux server and used to back up directories, service data, or even entire block devices—regardless of whether the server runs Proxmox VE or not.

In this article, I want to share not only the technical capabilities of the PBS Client, but also explain why it has become part of my strategy for building a simple and maintainable infrastructure.

The Problem I Was Trying to Solve

Almost every new Linux server requires backups. Previously, the typical scenario looked pretty much the same:

  • Bash script + cron;
  • Bash script executed by Jenkins;
  • Restic;
  • BorgBackup;
  • rsync for specialized tasks.

All of these solutions work. The problem is not with them. The problem is that every new tool adds another component that needs to be maintained: its own configuration, automation, logging, monitoring, updates, documentation, and separate recovery procedures.

Eventually, this "minor" infrastructure starts consuming more and more time. That's when I started asking myself a simple question: "Doesn't the tool already running in my infrastructure do this?"

Why Proxmox Backup Client

Proxmox Backup Server was already in use for virtual machine backups. So instead of deploying another backup system, I decided to take a closer look at the official proxmox-backup-client.

It turned out its capabilities are more than sufficient for most Linux servers.

What I Back Up

Today, the PBS Client is used to back up:

  • Docker Volumes;
  • application directories;
  • /etc, Nginx, and HAProxy configurations;
  • PostgreSQL and MySQL dumps;
  • Git repositories;
  • user home directories;
  • system service directories;
  • individual block devices.

Essentially almost everything that is not a virtual machine.

File-Level Backups

For backing up directories, the pxar (Proxmox File Archive) format is used:

proxmox-backup-client backup etc.pxar:/etc \
    --repository root@pam@pbs:backup

The pxar format reliably preserves:

  • permissions and file owners;
  • Access Control Lists (ACL);
  • symbolic links;
  • extended attributes;
  • timestamps.

Thus, after restoration, we get a highly precise, working copy of the filesystem.

Block Device Backups

This capability is, in my opinion, the most underestimated. The PBS Client allows you to back up not just directories, but entire block devices.

For example:

proxmox-backup-client backup disk.img:/dev/sda \
    --repository root@pam@pbs:backup

This is especially convenient for physical servers, Raspberry Pi, industrial computers, edge devices, and any Linux systems that do not run directly under Proxmox VE but require fast "bare metal" recovery.

How Deduplication Works

One of the main advantages of PBS is chunk-level deduplication. Each backup looks like a full snapshot, but the client physically transmits only new or modified data chunks. Thanks to this:

  • subsequent backups run much faster;
  • minimal network bandwidth is consumed;
  • backup storage space is used highly efficiently.

Additionally, PBS provides global deduplication (across different hosts within the same datastore), compression, client-side encryption, regular data integrity verification on the server, and automatic retention policies.

Metadata Change Detection

In newer versions of the PBS Client, an optimized comparison mode is available:

--compare-content metadata

In this mode, the client quickly analyzes file metadata (mtime, size) and does not read unchanged files for hashing. For large directories containing hundreds of thousands of files, this drastically reduces backup duration and disk I/O load on the client host.

Data Restoration

Restoring a directory is done with just a single command:

proxmox-backup-client restore etc.pxar ./restore \
    --repository root@pam@pbs:backup

In addition, PBS supports interactive mounting of archives via FUSE with the proxmox-backup-client mount command. This allows selective file recovery without needing to extract or download the entire archive.

This is why I recommend regularly testing not just backup creation, but the restoration process itself. A backup that has never been tested is merely an assumption that it works.

How I Automate Backups

Previously, my backups were triggered via cron or Jenkins pipelines with a bunch of Bash scripts. Today, I almost always use systemd timers. This provides several key advantages:

  • centralized management and status monitoring via systemctl;
  • automatic logging of stdout/stderr to journald;
  • ability to configure service dependencies (e.g., triggering a backup only after database dumps complete);
  • easier troubleshooting on failures.

For modern Linux systems, this is a much more natural and reliable way of automation than cron.

Practical Nuances

Before implementing PBS Client, there are a few important points to consider:

  • HTTPS and Network: The client communicates with PBS via HTTPS (port 8007 by default). In closed networks, firewall, VPN, or reverse proxy settings might be required.
  • TLS: If a self-signed certificate is used on the PBS, you must explicitly specify the server's SSL fingerprint or add the certificate to trusted stores.
  • Performance: Deduplication and encryption consume CPU resources on the client host during chunk preparation.
  • Supported OS: Proxmox Backup Client is designed for Linux. There is currently no native client for Windows, so Windows servers require other tools or intermediate migration steps.

When PBS Client is a Good Choice

In my opinion, it is a great fit for Docker hosts, physical Linux servers, Git servers, edge devices (like Raspberry Pi), configuration directory backups, and in environments where Proxmox Backup Server is already successfully utilized for virtual machines.

When I Would Choose Another Solution

PBS Client is not a universal answer. I would consider alternatives if:

  • Windows systems must be backed up without intermediate layers;
  • there is no possibility or desire to maintain a standalone Proxmox Backup Server instance;
  • the team has already built reliable workflows around Restic, Borg, or Veeam, and replacing them yields no obvious benefit.

At the same time, modern versions of PBS support S3-compatible object storage as a datastore backend. This allows using cloud storage as part of a 3-2-1 backup strategy. When planning such an architecture, it's important to evaluate not just storage costs, but also API request pricing, egress traffic fees, and restoration speed.

Architectural Approach

I don't think Proxmox Backup Client is the best tool for every scenario. But if Proxmox Backup Server is already running in the infrastructure, it is logical to first maximize its utility before adding new components. This approach reduces the number of services, unifies backup policies, simplifies monitoring, and standardizes the restoration process.

Conclusion

For me, Proxmox Backup Client became an example of how an existing tool can solve a much wider range of tasks without introducing tool sprawl. It allowed me to make the infrastructure simpler: fewer separate tools, fewer custom scripts, a unified approach to backing up Linux systems, and fewer components to maintain for years. And these are the kinds of solutions that, in my opinion, best stand the test of time.

Related Notes