pgmoneta: a PostgreSQL backup daemon in C, with incremental chains and PITR

The gap pgmoneta fills: a backup daemon that is not the database

PostgreSQL ships pg_dump and pg_basebackup, and both are fine at what they do. Neither is a backup system. pg_dump gives you a logical copy with no incremental chain; pg_basebackup gives you one physical copy per invocation, and keeping a schedule of those means writing your own retention, compression and shipping logic around it. pgmoneta is the layer that was missing: a long-running process that owns the backup directory, decides when a full or incremental backup happens, streams WAL alongside it, and exposes the result to a CLI and a metrics endpoint.

The intended user is an operator running a self-managed PostgreSQL cluster on a Linux or BSD host, on a machine where a C daemon and a systemd unit are acceptable. The README lists Fedora 42+, RHEL 10.x, Rocky Linux 10.x, AlmaLinux 10.x, FreeBSD and OpenBSD as tested platforms. That list is narrow and deliberate: no macOS, no Windows, no container image mentioned. If your PostgreSQL runs in Kubernetes under an operator that already schedules base backups, pgmoneta duplicates work you have already paid for.

Process model, shared memory and libev: how the daemon is built

The README's Overview section is short and worth reading literally. pgmoneta uses "a process model", "a shared memory model across processes", libev for network interactions and atomic operations to track state. That is a forking server in the Postfix or nginx mould, not a thread pool with a garbage collector. State that survives a worker lives in shared memory; state that does not lives in the child. The atomic operations exist because several processes read and write that shared state without a lock around every field.

The consequence for an operator is that pgmoneta has no runtime to warm up and no interpreter to install. It also means a crash in a worker is a process death, not a corrupted heap shared with the rest of the daemon. The cost is that debugging a misbehaving build means reading C and, per the README, setting log_level to debug5 in a Debug build. The repository carries a benchmarks/ directory and a clang-format.sh script, so the project at least keeps a formatting baseline and some performance material in tree.

Backups themselves are physical. The feature list mentions tablespace support for full backups, incremental backups for PostgreSQL 14+ with tablespace support only from PostgreSQL 17+, compression through gzip, zstd, lz4 and bzip2, and AES encryption at rest. Those are properties of the stored files, which is why the daemon can also serve them back for a restore.

Installing pgmoneta from the PGDG repository and taking a first backup

On RPM-based distributions the README points at the PostgreSQL YUM repository. You add the PGDG repository first, then install the package. The README gives this example for Fedora, RHEL, Rocky Linux and AlmaLinux 10:

dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-10-x86_64/pgdg-redhat-repo-latest.noarch.rpm

With the repository in place, the package install is a single command:

dnf install -y pgmoneta

One detail the README states plainly and that saves confusion: pgmoneta does not rely on the PostgreSQL binaries. You can install it before or without a local PostgreSQL server. If you do want a server on the same host for testing, the README disables the distribution module and installs a specific version, shown here for PostgreSQL 18:

dnf -qy module disable postgresql
dnf install -y postgresql18 postgresql18-server

After that, the README hands off to doc/GETTING_STARTED.md for first-run configuration, and doc/CONFIGURATION.md for the option reference. It does not inline a minimal configuration file, so the exact keys for the backup directory, the WAL shipping settings and the TLS material have to come from those two documents. What the README does confirm is the shape of the workflow: you configure the daemon, start it (daemon mode with systemd integration is a listed feature), and then drive it remotely with pgmoneta-cli or pgmoneta-mcp. The web console, documented in doc/CONSOLE.md, is the read-only view over the same metrics.

If you prefer source, the release build is a standard CMake sequence, with clang named as the compiler and /usr/local as the install prefix:

git clone https://github.com/pgmoneta/pgmoneta.git
cd pgmoneta
mkdir build
cd build
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_INSTALL_PREFIX=/usr/local ..
make
sudo make install

The dependency list is long: libev, OpenSSL, zlib, zstd, lz4, bzip2, systemd, libssh, libarchive and rst2man for the man pages. The README provides a single dnf line that installs all of them on Fedora or RHEL, which is the honest way to present a build like this. A Debug build swaps the install prefix for -DCMAKE_BUILD_TYPE=Debug and, per the README, you should then set log_level to debug5.

Incremental backups are version-gated, and that is the real constraint

The feature list contains two version numbers that determine whether pgmoneta is a good fit at all. Incremental backup needs PostgreSQL 14 or newer. Tablespace support inside incremental backups needs PostgreSQL 17 or newer. Full backups support tablespaces on older releases. So a cluster on PostgreSQL 13 can use pgmoneta for full backups and WAL streaming, but not for the incremental chain that makes frequent backups affordable.

The README also advertises "intuitive backup chain management" without describing the chain format in the page. How a chain is stored, how many increments sit behind a full backup, and what happens when one link is missing are questions the README does not answer; doc/ARCHITECTURE.md and the user guide under doc/manual/en are where that would live. Treat the chain as the thing to test before you depend on it, not the thing to assume.

There is a second boundary worth naming. pgmoneta is a physical backup tool. It restores a data directory and replays WAL to a point in time. It is not a logical migration tool, it does not give you a portable dump you can load into a different major version, and it does not do table-level restore. If your actual requirement is "move this schema to another server" or "recover one dropped table", pgmoneta is the wrong instrument, and pg_dump or pg_restore is the right one.

Hot standby, WAL tools and the Prometheus endpoint

Three features sit outside the backup path and are worth separating from it. The first is hot standby: pgmoneta can keep a warm copy of the cluster ready. The README states the capability without describing the promotion mechanism, so whether that standby is promoted by pgmoneta or by your own tooling is not something the page answers.

The second is the WAL tooling. pgmoneta can inspect WAL records and, per the README, "optionally filter them out". Filtering WAL records is a sharp instrument: it is useful for building a reduced replica or for cutting noise out of a stream, and it is dangerous if applied to the only copy of the WAL a restore depends on. The README does not document a guard against that, so the safe reading is that filtering belongs on a copy, not on the archive you intend to restore from.

The third is observability. A Prometheus metrics endpoint and a web console are listed, and the console is documented separately in doc/CONSOLE.md. For an operator this is the part that makes a daemon acceptable: a backup process you cannot see is a backup process you cannot trust. Offline detection of unreachable instances is listed alongside it, which is the failure signal you want before a scheduled backup silently stops working.

How pgmoneta differs from pgBackRest and Barman

pgmoneta is not the first tool in this space, and the difference is architectural rather than feature-by-feature. pgBackRest is the long-established comparison point: it is also a physical backup tool with full, differential and incremental backups, parallel compression and a repository model, and it is written in Perl and C with a large configuration surface. Barman takes a different route again, acting as a backup server that manages multiple PostgreSQL instances over SSH, with its own catalog and retention policies.

Where pgmoneta positions itself is as a C daemon with a small process model, a shared memory state layer, libev networking and a remote control plane in pgmoneta-cli plus an MCP server and client for natural-language interaction. The MCP pair is the genuinely distinctive item on the feature list; neither pgBackRest nor Barman ships one, and it is the reason the project appears in discussions about driving infrastructure from an assistant. The trade-off is maturity and ecosystem: pgBackRest and Barman have years of documented recovery procedures behind them, and pgmoneta's README defers its own operational detail to separate documents. If your team already runs pgBackRest successfully, switching to pgmoneta buys you the MCP interface and a different process model, and costs you the familiarity of a tool your on-call engineers already know how to restore from.

Licence, maintenance and what an upgrade actually costs

pgmoneta is BSD-3-Clause. That is a permissive licence: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text are retained. It is not copyleft, so linking it into a product does not oblige you to publish your own source. This is a description of the licence text, not legal advice; if the backup tool is part of something you ship, have counsel read the LICENSE file in the repository root.

The maintenance picture is concrete. The most recent release is 0.21.0, dated 2026-04-29, following 0.20.0 on 2026-01-19 and 0.19.1 on 2025-08-31. The repository is not archived. The last push to the default branch was on 2026-04-29, which is the same date as the 0.21.0 release. The version numbers are still in the 0.x range, which is the project's own signal that interfaces can move between minor releases.

Upgrade cost therefore falls in two places. First, configuration: doc/CONFIGURATION.md is the reference, and a 0.x minor bump is the point at which to diff it against your running config rather than assume compatibility. Second, the backup chain: an incremental chain written by one version has to be readable by the next, and the README does not document a chain format guarantee. The practical check before upgrading a production daemon is to confirm that the new build can restore a chain created by the old one, using a copy of the archive rather than the archive itself.

Editorial conclusion

Adopt pgmoneta if you run PostgreSQL yourself on Fedora, RHEL, Rocky Linux, AlmaLinux, FreeBSD or OpenBSD, need incremental backups and point-in-time restore, and want a daemon you can reach over TLS with pgmoneta-cli or pgmoneta-mcp. Do not adopt it if you only use managed PostgreSQL and cannot install a daemon on the database host, or if you need a graphical administration suite rather than a backup tool. Before trusting it, verify one thing first: that a restore of an incremental chain from your own cluster completes and that the resulting data directory starts, because the README documents backup and restore as features but says nothing about automated verification of a restored cluster.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes