Proxmox Backup Server in a container, and the three features you lose

An unofficial container compilation of a Debian system, not a rewrite

The repository describes itself plainly: an unofficial compilation of Proxmox Backup Server to run it in a container for AMD64 and ARM64. The word compilation is the important one. The artefacts in the GitHub releases are the archived Debian installation files with their install script, plus a statically linked backup client, so what runs in the container is the upstream Proxmox software built for a distribution that was not designed to live in one.

The sources are the upstream ones, and the author is named at the end of the README, with a 2020 to 2025 date range. The build machinery is in the repository too, with a PROCESS.md document describing how to recompile, a release.bash script, a VERSION file, dockerfiles directory and a packages directory.

The audience is narrow but real. Proxmox Backup Server normally wants to be installed on a Proxmox VE host, and plenty of people have a NAS, a Raspberry Pi class ARM board or a small virtualised host where they would rather not install Proxmox VE just to keep backups. This packaging removes that obstacle.

The README is also blunt about the cost: running in a container might result in some functions not working properly, and the invitation to open an issue for debugging is the way those get fixed. That is the operating model to expect, an issue tracker rather than a support channel.

The compose file tells you exactly what the container gets and gives up

The shipped docker-compose.yml is short and worth reading line by line, because it is the entire deployment description. The service is named pbs and the image is parameterised twice, with IMAGE and TAG environment variables defaulting to ayufan/proxmox-backup-server and latest.

    image: ${IMAGE:-ayufan/proxmox-backup-server:${TAG:-latest}}
    ports:
      - 8007:8007
    mem_limit: 2G

Port 8007 is published on the same port, and the memory limit is 2G. The three named volumes hold the configuration, the logs and the library, which is the state that has to survive a container replacement.

    volumes:
      - pbs_etc:/etc/proxmox-backup
      - pbs_logs:/var/log/proxmox-backup
      - pbs_lib:/var/lib/proxmox-backup
    tmpfs:
      - /run
    cap_add:
      - SYS_RAWIO # smartctl support

The tmpfs entry for /run is not cosmetic, and the README says so in the common problems section: it is a requirement of the 2.1.x series, and missing it is what produces the authentication failure people see with admin@pbs. The capability SYS_RAWIO is there for smartctl support, and the matching device lines for /dev/sda and /dev/sdb are present but commented out, so exposing drives is a decision you make explicitly.

The restart policy is unless-stopped and the stop signal is SIGHUP, which is what you want for a service that should survive a reboot and shut down the way the upstream daemon expects.

Pull an image, fetch the compose file, and change the default password

Starting from a clean machine takes three commands. The images are precompiled and published on Docker Hub for both architectures, with a stable tag and a beta tag that tracks the pre-releases.

docker pull ayufan/proxmox-backup-server:latest

docker pull ayufan/proxmox-backup-server:beta

The compose file is not in the image, it is fetched from the repository, which keeps the deployment description in version control next to the rest of your configuration.

wget https://raw.githubusercontent.com/ayufan/pve-backup-server-dockerfiles/refs/heads/main/docker-compose.yml
docker-compose up -d

The beta variant is the same file with a TAG override in front of the command.

TAG=beta docker-compose up -d

After that, the web interface is on port 8007 of the host, and the README states the initial credentials and then tells you to change the password.

docker-compose exec server proxmox-backup-manager cert info | grep Fingerprint

That last command is not for the login itself but for the next step. Because the container generates its own certificate, the server is self signed, and adding it to Proxmox VE means reading the fingerprint so you can paste it into the PBS integration tutorial at pbs.proxmox.com. Getting the fingerprint out of the running container before you enrol it is the step that saves time.

One note on the compose file: the service in the shipped file is called pbs, while the exec example in the README uses a service called server. Check the service name in your copy before running exec commands against it.

ZFS, shell access and PAM authentication are the three that do not work

The README lists the features that do not work because of the container architecture, and it is a short list with a reason attached to each, which is what makes it useful. ZFS is not installed in a container. Shell access does not make sense in an ephemeral container environment, and because the PVE authentication method is used rather than PAM, there is no interactive shell to give. PAM authentication is missing because containers are by definition ephemeral and no /etc/ configs are being persisted.

The ZFS one has a direct consequence for anyone coming from Proxmox VE. Proxmox Backup Server normally stores datastores on ZFS, and this build has no ZFS at all, so the datastore has to live on a plain filesystem or a bind mount. That is fine for a single-disk or plain-directory setup, and it is a real loss for anyone who relies on ZFS snapshots as part of their backup retention story.

The shell one matters for operations. There is no way to drop into the container and poke at it, which means troubleshooting happens through the manager commands rather than through an interactive session, and it means the habit of inspecting a running system before changing it does not apply here.

The PAM one changes the security posture in a way worth being explicit about. The password set in the web interface is stored in the persisted configuration volume, so it does survive a restart. But the user database is not an LDAP or AD bind, so an organisation that manages backup operator accounts centrally loses that integration.

The README is careful elsewhere too, saying that the core features should work. The features it names as broken are the exceptions, not the rule.

The tmpfs mount and the Synology kernel are the two documented failure modes

The common problems section is short and concrete, which is a good sign about the kind of support this project can offer. The first entry is the authentication failure with admin@pbs, and the fix is to ensure that /run is mounted to tmpfs, which the README calls a requirement of the 2.1.x series. This is a version-specific requirement, so the tmpfs entry in the compose file is not optional decoration.

The second entry is a hardware corner: some Synology devices run a really old kernel, 3.1, and for those a specific pull request is needed and the image has to be recompiled manually. That is a compile-from-source detour for a specific NAS model, and the README links the pull request rather than explaining the change.

Neither of these is a code bug, and both are the kind of problem that appears on a device the maintainer does not have. The general lesson is that this container behaves like a normal container image with a normal set of host assumptions, and the assumptions are written down, but the coverage of unusual hardware is thin.

A third, quieter failure mode comes from the version scheme. The tags on Docker Hub and the release tags on GitHub carry a packaging suffix, with releases such as v4.2.0-1, v4.1.9-1 and v4.0.21-1, so the upstream Proxmox Backup Server version is the part before the dash and the packaging revision is the part after it. When you compare a client on a Proxmox VE host with the server container, that is the string to compare.

Overriding the compose file covers datastores, timezones, SMART and persisted state

Everything beyond the first run is done with docker-compose.override.yml, which Docker merges with the base file automatically. The pattern is the same in all four cases: create a new file, or merge into an existing one, and add a services entry for pbs.

The first override adds a datastore volume. The named volume uses the local driver with a bind mount to a host path, and the device is the path you want the backups to land on.

services:
  pbs:
    volumes:
      - backups:/backups

volumes:
  backups:
    driver: local
    driver_opts:
      type: ''
      o: bind
      device: /srv/dev-disk-by-label-backups

The datastore itself is then created in the web interface at https://<IP>:8007/. The second override sets the timezone through an environment variable.

services:
  pbs:
    environment:
      TZ: Europe/Warsaw

The third exposes the drives and grants the capability needed to read SMART parameters through the interface.

services:
  pbs:
    devices:
      - /dev/sda
      - /dev/sdb
    cap_add:
      - SYS_RAWIO

The fourth, which the README marks as optional but advised, persists the configuration, the logs and the library as bind mounts to host paths, so that a recreated container keeps its state and the logs survive a rebuild.

Bare metal is the answer when the container limits start to matter

The README offers a native path for people who find the container restrictions inconvenient, and the framing is direct: Docker is convenient, but in some cases it might simply be better to install natively. The mechanism is the same archived Debian artefacts from the GitHub releases, extracted and installed with the included script.

wget https://github.com/ayufan/pve-backup-server-dockerfiles/releases/download/v4.0.12/proxmox-backup-server-v4.0.12-$(dpkg --print-architecture).tgz
tar zxf proxmox-backup-server-*.tgz
proxmox-backup-server-*/install

The architecture suffix comes from dpkg, so the same commands work on AMD64 and ARM64 hosts. The README reminds you to replace the version in the URL with the latest one.

The client is distributed the same way, as a statically linked binary that does not need the host to have anything installed. The README flags one architecture as unstable, arm32, which is considered able to back up but likely unable to restore data.

wget https://github.com/ayufan/pve-backup-server-dockerfiles/releases/download/v4.0.12/proxmox-backup-client-v4.0.12-$(dpkg --print-architecture).tgz
tar zxf proxmox-backup-client-*.tgz
proxmox-backup-client-*/proxmox-backup-client.sh

This is the real alternative to the container, and the difference in approach is that the native install keeps the parts of Proxmox Backup Server the container has to drop: a real filesystem for ZFS, a real /etc/ for PAM, and a shell to administer it. What it costs is a distribution that has to be managed by hand, with no image to pull when upstream ships a fix.

An unofficial, unmaintained build with a fast release cadence and no licence file

The repository description says unofficial, and unmaintained, and that is the first fact to accept. The release history, however, looks busy, with v4.2.0-1 published on 2026-05-15, v4.1.9-1 on 2026-05-07 and v4.0.21-1 on 2025-11-22. The pattern suggests the container is rebuilt when upstream Proxmox Backup Server moves, which is exactly what you want from a packaging project, but it also means the container version is dictated by upstream and the packaging layer has no release of its own to speak of.

The last push was on 2026-05-15, and the repository is not archived. That is several months before the current date, and it means the image you pull today is not necessarily built from the newest upstream code.

Licensing is the other open point. No licence is identified for the repository, and there is no LICENSE file among the top level entries, which are the build scripts, the dockerfiles directory, the compose file, PROCESS.md, RELEASE.md, VERSION, env.bash, packages, repos and scripts. The upstream Proxmox sources carry their own terms, but the packaging layer here does not state any, and a redistribution question is one to settle before this image goes into a distribution you ship to someone else.

There is also a sponsorship link in the README, so the maintenance of this packaging depends on a single person with limited time, which is worth knowing before you make it the home of your backups.

Editorial conclusion

Use this build when you want Proxmox Backup Server running on a NAS or a lightweight virtualised host and you are willing to live without ZFS, without shell access and without PAM authentication. Do not use it as the backup target for a Proxmox VE cluster that depends on those features, and do not treat it as a supported product, since the project describes itself as an unofficial and unmaintained compilation. Verify three things before you migrate any real backup onto it: that /run is mounted as tmpfs, which the authentication failure in the common problems section is tied to, that your datastore path exists on the host before the first backup, and that the version you pull matches the Proxmox Backup Server release your Proxmox VE hosts expect, since the container tags track upstream versions with a packaging suffix.

Frequently asked questions

Official sources

1. ayufan/pve-backup-server-dockerfiles on GitHub
2. Issues
3. README
4. Releases