BackupPC: dependencies, pooling, and version 4.4.1rc1

A backup server that installs nothing on the client

BackupPC runs on a server and pulls data off machines you back up, which is the design decision that defines it. Data is extracted over SMB using Samba, over rsync, or as a tar stream over ssh, rsh or nfs. On a Windows client that means the standard smb protocol, so there is no agent to deploy, no service to keep alive, and nothing that has to survive an operating system upgrade.

That model covers the awkward case the README calls out directly: laptops with dynamic IP addresses on DHCP that are only intermittently connected. A pull model tolerates a host that is simply absent, where a push model needs a registration protocol and credentials on every device.

The repository is Perl, with `lib/`, `bin/`, `conf/`, `cgi-bin/`, `httpd/`, `systemd/` and `configure.pl` at the top level, plus `doc-src/` as the documentation source and a `cpanfile` for Perl dependencies. Copyright is Craig Barratt, 2001-2025.

It is worth being blunt about what this is not. It is not a disk imaging product, and the storage model is a pool on a filesystem, not an object store with per-object checksums.

Installation needs three downloads before configure.pl runs

The Quick Start is where the real friction sits. BackupPC proper comes from the GitHub releases page, but it will not build without two companion projects that live in their own repositories:

tar zxf BackupPC-__VERSION__.tar.gz
cd BackupPC-__VERSION__
perl configure.pl

Before those commands you need the Perl module BackupPC::XS from github.com/backuppc/backuppc-xs/releases, and the server side rsync from github.com/backuppc/rsync-bpc/releases. If you plan to back up Windows clients over SMB you additionally need `smbclient` and `nmblookup` from the Samba distribution.

`configure.pl` probes the system and prompts for install paths. Its options are documented in the script itself, readable with `perldoc configure.pl`.

Pooling is the reason disk costs stay flat

The storage scheme is the project's actual contribution. Identical files across multiple backups of the same or different machines are stored once, and compression is applied on top. The README gives a worked example: 95 laptops with full backups averaging 3.6GB and incrementals about 0.3GB each, storing three weekly fulls and six incrementals per laptop is about 1200GB of raw data, which pooling and compression bring down to roughly 150GB.

That ratio is the argument, and also the trap. Pooling means the backup store is not a set of independent archives. Restoring a file walks back through the pool, and a corrupted pool entry affects every host that referenced that content. There is no per-host deletion: dropping one machine from a retention policy does not free the space it contributed, because other backups still reference those files.

Configuration allows parallel backups, per-share and per-directory selection with exclusions, separate full and incremental schedules, and all of it settable system-wide or per PC. Reminder emails for machines not backed up recently are also configurable in content, timing and policy.

Restore paths from a CGI interface, with a real difference between them

The web interface is described as http/cgi: administrators view logs, configuration and current status, and users start and cancel backups and browse backups.

Three restore routes exist, and they differ in ways that matter operationally. A single file can be downloaded straight from any backup through the CGI. Zip or tar archives of selected files or directories can be downloaded the same way. And a restore can be pushed directly to the client machine using SMB, rsync or tar.

The push-back route is the one with a failure mode worth naming: it writes to the live machine, not to a snapshot, so a mistargeted path overwrites current user data. The download routes are the safe default for anything except a machine already known to be decommissioned.

The CGI layer is also the whole authentication story. There is no separate identity provider described here, so how access is controlled depends on the web server or proxy you put in front of `cgi-bin/`. An internet-exposed BackupPC without a properly configured front end is a file listing of your whole estate.

Version 4.4.1rc1 after a six year gap

The release history is the weakest part of this project and the most important thing to check before adopting.

4.4.0 was released on 2020-06-20 and 4.3.2 on 2020-02-17. Then 4.4.1rc1 was released on 2025-11-13, described as the first release candidate for 4.4.1 with a new maintainer. A new maintainer on the first candidate in a long gap also means the candidate itself is where you find out whether the Perl dependencies listed in the `cpanfile` still resolve on your distribution's Perl. Assume you will be reading ChangeLog rather than release notes.

The README also flags a gap in its own right: BackupPC 4.x does not have packages available for all the main Linux distributions, and it asks for help creating them. So a source install is the baseline path, not a fallback.

Where BackupPC sits against the alternatives

The alternative worth naming is an agent-based tool, whether that is a commercial endpoint product or a script that pushes to storage. The approach difference is where the code executes and who holds the credentials.

With BackupPC the server holds the SMB or ssh credentials for every machine and opens the connection. Machines need no software, and a machine you have never seen fails by refusing a connection rather than by missing an agent. What you give up is anything requiring the endpoint: file-level restore of locked or encrypted data, and backup of state that only exists while a machine is on and reachable by a user session.

For archives, the README's own position is that BackupPC is the primary store and that additional permanent archives should be created by periodically backing up the server itself to tape. That is an additional system to run, not a feature to configure, and it should be costed before you assume the backup is complete.

Documentation ships with the release in doc/BackupPC.pod and doc/BackupPC.html, readable with `perldoc` or a browser.

Editorial conclusion

BackupPC fits an administrator consolidating backups from many Windows and Linux machines onto one server disk, especially laptops on DHCP that connect intermittently, since it needs no client agent and pools duplicate files across hosts. It does not fit a team wanting a modern web UI, a current release cadence, or distributed packages: the README itself asks for help packaging 4.x, and 4.4.1 is still a release candidate. Verify first that `perl configure.pl` completes against your disk layout and that you can install BackupPC::XS and rsync-bpc from their own release pages, because those two live in separate repositories and a missing one stops the install before any backup runs.

Frequently asked questions

Official sources

1. backuppc/backuppc on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases