docs: Correct and clarify wal-g backup documentation.

Backups are written every 16k of WAL archive, and by default do not
have an upper limit on how out of date they are, as `archive_timeout`
defaults to 0.

Also emphasize that these are streaming backups, not just one
point-in-time backup daily.

Fixes #21976.
This commit is contained in:
Alex Vandiver 2022-05-07 00:21:44 +00:00 committed by Tim Abbott
parent ba5cf331a2
commit 18230fcd99
2 changed files with 15 additions and 5 deletions

View File

@ -553,8 +553,8 @@ Zulip's configuration allows for [warm standby database
replicas][warm-standby] as a disaster recovery solution; see the replicas][warm-standby] as a disaster recovery solution; see the
linked PostgreSQL documentation for details on this type of linked PostgreSQL documentation for details on this type of
deployment. Zulip's configuration builds on top of `wal-g`, our deployment. Zulip's configuration builds on top of `wal-g`, our
[database backup solution][wal-g], and thus requires that it be [streaming database backup solution][wal-g], and thus requires that it
configured for the primary and all secondary warm standby replicas. be configured for the primary and all secondary warm standby replicas.
In addition to having `wal-g` backups configured, warm standby In addition to having `wal-g` backups configured, warm standby
replicas should configure the hostname of their primary replica, and replicas should configure the hostname of their primary replica, and

View File

@ -437,7 +437,8 @@ Once that's done, you can simply re-run the import process.
The [Zulip-specific backup tool documented above](#backups) is perfect The [Zulip-specific backup tool documented above](#backups) is perfect
for an all-in-one backup solution, and can be used for nightly for an all-in-one backup solution, and can be used for nightly
backups. For administrators wanting continuous point-in-time backups, backups. For administrators wanting continuous point-in-time backups,
Zulip has built-in support for taking daily incremental backups using Zulip has built-in support for taking daily backup snapshots along
with [streaming write-ahead log (WAL)][wal] backups using
[wal-g](https://github.com/wal-g/wal-g) and storing them in Amazon S3. [wal-g](https://github.com/wal-g/wal-g) and storing them in Amazon S3.
By default, these backups are stored for 30 days. By default, these backups are stored for 30 days.
@ -460,11 +461,20 @@ s3_backups_bucket = # name of S3 backup bucket
1. Run `/home/zulip/deployments/current/scripts/zulip-puppet-apply`. 1. Run `/home/zulip/deployments/current/scripts/zulip-puppet-apply`.
Daily full-database backups will be taken at 0200 UTC, and every WAL Daily full-database backups will be taken at 0200 UTC, and every WAL
log will be written to S3 as it is saved by PostgreSQL; by default, archive file will be written to S3 as it is saved by PostgreSQL; these
this happens every 5 minutes, or every 1G, whichever happens first. are written every 16KiB of the WAL. This means that if there are
periods of slow activity, it may be minutes before the backup is saved
into S3 -- see [`archive_timeout`][archive-timout] for how to set an
upper bound on this. On an active Zulip server, this also means the
Zulip server will be regularly sending PutObject requests to S3,
possibly thousands of times per day.
If you need always-current backup availability, Zulip also has If you need always-current backup availability, Zulip also has
[built-in database replication support](deployment.md#postgresql-warm-standby). [built-in database replication support](deployment.md#postgresql-warm-standby).
You can (and should) monitor that backups are running regularly via You can (and should) monitor that backups are running regularly via
the Nagios plugin installed into the Nagios plugin installed into
`/usr/lib/nagios/plugins/zulip_postgresql_backups/check_postgresql_backup`. `/usr/lib/nagios/plugins/zulip_postgresql_backups/check_postgresql_backup`.
[wal]: https://www.postgresql.org/docs/current/wal-intro.html
[archive-timeout]: https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT