paulmataruso/zulip
1
0
Fork 0
mirror of https://github.com/zulip/zulip.git synced 2025-11-04 14:03:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Correct and clarify wal-g backup documentation.

Browse Source 
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.

(cherry picked from commit 18230fcd99)
This commit is contained in:
Alex Vandiver
2022-05-07 00:21:44 +00:00
parent 09678193c9
commit 4fa62a25e2
2 changed files with 15 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/production/deployment.md
View File

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

16
docs/production/export-and-import.md
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
for an all-in-one backup solution, and can be used for nightly
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.
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`.
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,
this happens every 5 minutes, or every 1G, whichever happens first.
archive file will be written to S3 as it is saved by PostgreSQL; these
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
[built-in database replication support](deployment.md#postgresql-warm-standby).
You can (and should) monitor that backups are running regularly via
the Nagios plugin installed into
`/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