... | ... | @@ -1608,4 +1608,138 @@ See also: |
|
|
|
|
|
## Alternatives considered
|
|
|
|
|
|
<!-- include benchmarks and procedure if relevant --> |
|
|
### Backup systems
|
|
|
|
|
|
The bespoke backup system described in the design section is only used
|
|
|
inside TPA (and probably also Debian's DSA team). It works, but it's
|
|
|
complex, and rather brittle. Let's see if there are better
|
|
|
alternatives out there.
|
|
|
|
|
|
#### Barman
|
|
|
|
|
|
[Barman](https://pgbarman.org) presumably makes "taking an online hot backup of
|
|
|
PostgreSQL" "as easy as ordering a good espresso coffee". It seems
|
|
|
well maintained (last release 3.2.0 on 20 October 20220, 7 days ago),
|
|
|
and with a healthy community (45 contributors, 7 with more than 1000
|
|
|
SLOC, 5 pending PRs, 83 open issues).
|
|
|
|
|
|
It is still seeing active development and new features, with a few
|
|
|
[sponsors](https://pgbarman.org/sponsor/) and [professional support](https://pgbarman.org/support/) from the company owning
|
|
|
the copyright ([EntrepriseDB](https://www.enterprisedb.com/)).
|
|
|
|
|
|
It's in Debian, and well maintained there (only day between the 3.2.0
|
|
|
release and upload to unstable). It's licensed under the GPLv3.
|
|
|
|
|
|
The documentation is a little confusing; it's a [one page HTML
|
|
|
page](https://docs.pgbarman.org/release/3.2.0/) or [a PDF on the release page](https://github.com/EnterpriseDB/barman/releases). The main command and
|
|
|
configuration files each have a manual page, and so do some
|
|
|
sub-commands, but not all.
|
|
|
|
|
|
Quote from the [about page](https://pgbarman.org/about/):
|
|
|
|
|
|
> **Features & Goals**
|
|
|
>
|
|
|
> * Full hot physical backup of a PostgreSQL server
|
|
|
> * Point-In-Time-Recovery (PITR)
|
|
|
> * Management of multiple PostgreSQL servers
|
|
|
> * Remote backup via rsync/SSH or pg_basebackup (including a 9.2+ standby)
|
|
|
> * Support for both local and remote (via SSH) recovery
|
|
|
> * Support for both WAL archiving and streaming
|
|
|
> * Support for synchronous WAL streaming (“zero data loss”, RPO=0)
|
|
|
> * Incremental backup and recovery
|
|
|
> * Parallel backup and recovery
|
|
|
> * Hub of WAL files for enhanced integration with standby servers
|
|
|
> * Management of retention policies for backups and WAL files
|
|
|
> * Server status and information
|
|
|
> * Compression of WAL files (bzip2, gzip or custom)
|
|
|
> * Management of base backups and WAL files through a catalogue
|
|
|
> * A simple INI configuration file
|
|
|
> * Totally written in Python
|
|
|
> * Relocation of PGDATA and tablespaces at recovery time
|
|
|
> * General and disk usage information of backups
|
|
|
> * Server diagnostics for backup
|
|
|
> * Integration with standard archiving tools (e.g. tar)
|
|
|
> * Pre/Post backup hook scripts
|
|
|
> * Local storage of metadata
|
|
|
|
|
|
Missing features:
|
|
|
|
|
|
* streaming replication support
|
|
|
* S3 support
|
|
|
|
|
|
The design is actually eerily similar to the existing setup: it uses
|
|
|
`pg_basebackup` to make a full backup, then the `archive_command` to
|
|
|
stream WAL logs, at least in one configuration. It actually supports
|
|
|
*another* configuration which provides zero data loss in case of an
|
|
|
outage, as setups depending on `archive_command` actually can result
|
|
|
in data loss, because PostgreSQL commits the WAL file only in 16MB
|
|
|
chunks. See the discussion in [the Barman WAL archive](https://docs.pgbarman.org/release/3.2.0/#the-barman-wal-archive) for more
|
|
|
information on those two modes.
|
|
|
|
|
|
In any case, the architecture is compatible with our current setup and
|
|
|
it looks like a good candidate.
|
|
|
|
|
|
#### pg_rman
|
|
|
|
|
|
[pg_rman](https://github.com/ossc-db/pg_rman) is a "Backup and restore management tool for
|
|
|
PostgreSQL". It seems relatively well maintained, with a release in
|
|
|
late 2021 (1.3.14, less than a year go), and the last commit in
|
|
|
September (about a month ago). It has a smaller community than Barman,
|
|
|
with 13 contributors and only 3 with more than a thousand SLOC. 10
|
|
|
pending PRs, 12 open issues.
|
|
|
|
|
|
It's unclear where one would get support for this tool. There doesn't
|
|
|
seem to be commercial support or sponsors.
|
|
|
|
|
|
It doesn't appear to be in Debian. It is licensed under an unusual
|
|
|
BSD-like [license](https://github.com/ossc-db/pg_rman/blob/master/COPYRIGHT) requiring attribution to the `NIPPON TELEGRAPH
|
|
|
AND TELEPHONE CORPORATION`.
|
|
|
|
|
|
Documentation is [a single manpage](https://ossc-db.github.io/pg_rman/index.html).
|
|
|
|
|
|
It's not exactly clear how this software operates. It *seems* like
|
|
|
it's a tool to make PITR backups but only locally.
|
|
|
|
|
|
Probably not a good enough candidate.
|
|
|
|
|
|
#### repmgr
|
|
|
|
|
|
[repmgr](https://repmgr.org/) is a tool for "managing replication and failover in a
|
|
|
cluster of PostgreSQL servers. It enhances PostgreSQL's built-in
|
|
|
hot-standby capabilities with tools to set up standby servers, monitor
|
|
|
replication, and perform administrative tasks such as failover or
|
|
|
manual switchover operations".
|
|
|
|
|
|
It does not seem, in itself, to be a backup manager, but could be
|
|
|
abused to be one. It could be interesting to operate hot-standby
|
|
|
backup servers, if we'd wish to go in that direction.
|
|
|
|
|
|
It is developed by the same company as Barman, EntrepriseDB. It is
|
|
|
packaged in Debian.
|
|
|
|
|
|
No other investigation was performed on the program because its
|
|
|
designed was seen as compatible with our current design, but also
|
|
|
because EntrepriseDB also maintains Barman. And, surely, they wouldn't
|
|
|
have two backup systems, would they?
|
|
|
|
|
|
#### omniptr
|
|
|
|
|
|
[omniptr](https://github.com/omniti-labs/omnipitr) is another such tool I found. Its README is really
|
|
|
lacking in details, but it looks like something like we do, which
|
|
|
hooks into the `archive_command` to send logs... somewhere.
|
|
|
|
|
|
I couldn't actually figure out its architecture or configuration from
|
|
|
a quick read of the documentation, which is not a good sign. There's a
|
|
|
bunch of `.pod` files in a [doc directory](https://github.com/omniti-labs/omnipitr/tree/master/doc), but it's kind of a mess
|
|
|
in there.
|
|
|
|
|
|
It does not seem to be packaged in Debian, and doesn't seem very
|
|
|
active. The last release (2.0.0) is almost 5 years old (November
|
|
|
2017). It doesn't have a large developer community, only 8 developers,
|
|
|
none of them with more than a thousand lines of code (omniptr is small
|
|
|
though).
|
|
|
|
|
|
It's written in Perl, with [a license similar to the PostgreSQL
|
|
|
license](https://github.com/omniti-labs/omnipitr/blob/master/doc/LICENSE).
|
|
|
|
|
|
I do not believe it is a suitable replacement for our backup system. |