2026.10.11
pgmoneta: A Self-Hosted Backup and Restore Tool for PostgreSQL
pgmoneta provides full and incremental PostgreSQL backups, WAL handling, point-in-time recovery, compression, encryption, and monitoring. Review version, platform, migration, and recovery requirements before adoption.
Project scope
pgmoneta is a backup and restore solution for PostgreSQL. It is aimed at teams that want to control their backup data, recovery workflows, and operational monitoring in a self-hosted environment. The project uses the BSD-3-Clause license and is presented as a PostgreSQL backup tool, not as a replacement for PostgreSQL itself.
Known capabilities
The project supports full backups of PostgreSQL clusters and also provides incremental backups. The README states that incremental backups apply to PostgreSQL 14 and later, while tablespace support for incremental backups applies to PostgreSQL 17 and later. Restores can target a saved backup and include point-in-time recovery. WAL streaming is available for saving Write-Ahead Log segments as part of continuous backup and recovery workflows.
For storage, pgmoneta supports gzip, zstd, lz4, and bzip2 compression, along with AES encryption for backups at rest. The project website lists symbolic-link support, hot standby, and offline detection. The README also lists TLS 1.2+, daemon mode, a user vault, and a worker pool. Operations teams can expose Prometheus metrics, use a web console, and manage the service remotely. WAL tools are included for inspecting WAL records and optionally filtering them.
Who may benefit
pgmoneta may suit developers, small teams, and operations groups running PostgreSQL who want a self-hosted backup service. It is particularly relevant to environments already using WAL archiving, point-in-time recovery, or a warm standby workflow. Teams familiar with Linux service management, PostgreSQL archive settings, retention policies, and monitoring will likely find it easier to integrate into existing operations.
It may be more operationally involved than necessary for teams that only need occasional logical exports or have not planned separate backup storage, key management, and recovery exercises. The supplied sources do not confirm minimum hardware requirements, performance figures, broad cloud coverage, or a complete compatibility matrix. Those details should not be inferred from the listed features.
Deployment considerations
First, match the PostgreSQL version to the required capabilities, especially the documented version boundaries for incremental backups and tablespaces. The README lists Fedora 42+, RHEL 10.x, Rocky Linux 10.x, AlmaLinux 10.x, FreeBSD, and OpenBSD as tested platforms. A tested-platform list is not a guarantee for every operating-system and PostgreSQL combination.
Source builds require a compiler, CMake, libev, OpenSSL, compression libraries, systemd, libssh, libarchive, LibYAML, and other dependencies. With packages, verify that the distribution and repository match your deployment. Plan backup storage, WAL retention, compression and encryption keys, TLS certificates, credential permissions, and monitoring alerts separately. AES encryption does not replace key lifecycle management, and Prometheus metrics do not by themselves prove that backups are recoverable.
The 0.21.0 release deserves specific attention: its release notes mention changes to vault security and state that migration is required. Before upgrading, review the relevant configuration and migration documentation and validate backup, restore, WAL, and permission workflows in an isolated environment. Regardless of version, perform recovery exercises with representative data and verify recovery targets, backup chains, WAL continuity, and the manual steps required during an outage.
Sources
Sources checked: 2026-10-11