mirror of
https://github.com/zulip/zulip.git
synced 2025-11-03 13:33:24 +00:00
docs: Apply bullet style changes from Prettier.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
(cherry picked from commit 915884bff7)
This commit is contained in:
Anders Kaseorg
committed by
Tim Abbott
Tim Abbott
parent
5ae8fe292d
commit
0147c6adce
@@ -5,16 +5,16 @@ move data from one Zulip server to another, do backups, compliance
|
||||
work, or migrate from your own servers to the hosted Zulip Cloud
|
||||
service (or back):
|
||||
|
||||
* The [Backup](#backups) tool is designed for exact restoration of a
|
||||
- The [Backup](#backups) tool is designed for exact restoration of a
|
||||
Zulip server's state, for disaster recovery, testing with production
|
||||
data, or hardware migration. This tool has a few limitations:
|
||||
|
||||
* Backups must be restored on a server running the same Zulip
|
||||
- Backups must be restored on a server running the same Zulip
|
||||
version (most precisely, one where `manage.py showmigrations` has
|
||||
the same output).
|
||||
* Backups must be restored on a server running the same PostgreSQL
|
||||
- Backups must be restored on a server running the same PostgreSQL
|
||||
version.
|
||||
* Backups aren't useful for migrating organizations between
|
||||
- Backups aren't useful for migrating organizations between
|
||||
self-hosting and Zulip Cloud (which may require renumbering all
|
||||
the users/messages/etc.).
|
||||
|
||||
@@ -24,7 +24,7 @@ service (or back):
|
||||
document [backup details](#backup-details) for users managing
|
||||
backups manually.
|
||||
|
||||
* The logical [Data export](#data-export) tool is designed for
|
||||
- The logical [Data export](#data-export) tool is designed for
|
||||
migrating data between Zulip Cloud and other Zulip servers, as well
|
||||
as various auditing purposes. The logical export tool produces a
|
||||
`.tar.gz` archive with most of the Zulip database data encoded in
|
||||
@@ -41,13 +41,13 @@ service (or back):
|
||||
tool isn't applicable, including situations where an easily
|
||||
machine-parsable export format is desired.
|
||||
|
||||
* Zulip also has an [HTML archive
|
||||
- Zulip also has an [HTML archive
|
||||
tool](https://github.com/zulip/zulip-archive), which is primarily
|
||||
intended for public archives, but can also be useful to
|
||||
inexpensively preserve public stream conversations when
|
||||
decommissioning a Zulip organization.
|
||||
|
||||
* It's possible to set up [PostgreSQL streaming
|
||||
- It's possible to set up [PostgreSQL streaming
|
||||
replication](#postgresql-streaming-replication) and the [S3 file
|
||||
upload
|
||||
backend](../production/upload-backends.html#s3-backend-configuration)
|
||||
@@ -128,11 +128,11 @@ server, including the database, settings, secrets from
|
||||
The following data is not included in these backup archives,
|
||||
and you may want to back up separately:
|
||||
|
||||
* The server access/error logs from `/var/log/zulip`. The Zulip
|
||||
- The server access/error logs from `/var/log/zulip`. The Zulip
|
||||
server only appends to logs, and they can be very large compared to
|
||||
the rest of the data for a Zulip server.
|
||||
|
||||
* Files uploaded with the Zulip
|
||||
- Files uploaded with the Zulip
|
||||
[S3 file upload backend](../production/upload-backends.md). We
|
||||
don't include these for two reasons. First, the uploaded file data
|
||||
in S3 can easily be many times larger than the rest of the backup,
|
||||
@@ -140,7 +140,7 @@ and you may want to back up separately:
|
||||
exceed its disk capacity. Additionally, S3 is a reliable persistent
|
||||
storage system with its own high-quality tools for doing backups.
|
||||
|
||||
* SSL certificates. These are not included because they are
|
||||
- SSL certificates. These are not included because they are
|
||||
particularly security-sensitive and are either trivially replaced
|
||||
(if generated via Certbot) or provided by the system administrator.
|
||||
|
||||
@@ -159,7 +159,7 @@ backup strategy), and also serves as documentation for what is
|
||||
included in the backups generated by Zulip's standard tools. The
|
||||
data includes:
|
||||
|
||||
* The PostgreSQL database. You can back this up with any standard
|
||||
- The PostgreSQL database. You can back this up with any standard
|
||||
database export or backup tool. Zulip has built-in support for taking
|
||||
daily incremental backups using
|
||||
[wal-g](https://github.com/wal-g/wal-g); these backups are stored for
|
||||
@@ -179,12 +179,12 @@ PostgreSQL server to add:
|
||||
the Nagios plugin installed into
|
||||
`/usr/lib/nagios/plugins/zulip_postgresql_backups/check_postgresql_backup`.
|
||||
|
||||
* Any user-uploaded files. If you're using S3 as storage for file
|
||||
- Any user-uploaded files. If you're using S3 as storage for file
|
||||
uploads, this is backed up in S3. But if you have instead set
|
||||
`LOCAL_UPLOADS_DIR`, any files uploaded by users (including avatars)
|
||||
will be stored in that directory and you'll want to back it up.
|
||||
|
||||
* Your Zulip configuration including secrets from `/etc/zulip/`.
|
||||
- Your Zulip configuration including secrets from `/etc/zulip/`.
|
||||
E.g. if you lose the value of `secret_key`, all users will need to
|
||||
log in again when you set up a replacement server since you won't be
|
||||
able to verify their cookies. If you lose `avatar_salt`, any
|
||||
@@ -198,27 +198,27 @@ email), etc.
|
||||
|
||||
To restore from a manual backup, the process is basically the reverse of the above:
|
||||
|
||||
* Install new server as normal by downloading a Zulip release tarball
|
||||
- Install new server as normal by downloading a Zulip release tarball
|
||||
and then using `scripts/setup/install`. You don't need
|
||||
to run the `initialize-database` second stage which puts default
|
||||
data into the database.
|
||||
|
||||
* Unpack to `/etc/zulip` the `settings.py` and `zulip-secrets.conf` files
|
||||
- Unpack to `/etc/zulip` the `settings.py` and `zulip-secrets.conf` files
|
||||
from your backups.
|
||||
|
||||
* If you ran `initialize-database` anyway above, you'll want to run
|
||||
- If you ran `initialize-database` anyway above, you'll want to run
|
||||
`scripts/setup/postgresql-init-db` to drop the initial database first.
|
||||
|
||||
* Restore your database from the backup.
|
||||
- Restore your database from the backup.
|
||||
|
||||
* Reconfigure rabbitmq to use the password from `secrets.conf`
|
||||
- Reconfigure rabbitmq to use the password from `secrets.conf`
|
||||
by running, as root, `scripts/setup/configure-rabbitmq`.
|
||||
|
||||
* If you're using local file uploads, restore those files to the path
|
||||
- If you're using local file uploads, restore those files to the path
|
||||
specified by `settings.LOCAL_UPLOADS_DIR` and (if appropriate) any
|
||||
logs.
|
||||
|
||||
* Start the server using `scripts/restart-server`.
|
||||
- Start the server using `scripts/restart-server`.
|
||||
|
||||
This restoration process can also be used to migrate a Zulip
|
||||
installation from one server to another.
|
||||
@@ -233,8 +233,8 @@ that they are up to date using the Nagios plugin at:
|
||||
Zulip has database configuration for using PostgreSQL streaming
|
||||
replication. You can see the configuration in these files:
|
||||
|
||||
* `puppet/zulip_ops/manifests/profile/postgresql.pp`
|
||||
* `puppet/zulip_ops/files/postgresql/*`
|
||||
- `puppet/zulip_ops/manifests/profile/postgresql.pp`
|
||||
- `puppet/zulip_ops/files/postgresql/*`
|
||||
|
||||
We use this configuration for Zulip Cloud, and it works well in
|
||||
production, but it's not fully generic. Contributions to make it a
|
||||
@@ -300,10 +300,10 @@ archive of all the organization's uploaded files.
|
||||
1. [Install a new Zulip server](../production/install.md),
|
||||
**skipping Step 3** (you'll create your Zulip organization via the data
|
||||
import tool instead).
|
||||
* Ensure that the Zulip server you're importing into is running the same
|
||||
- Ensure that the Zulip server you're importing into is running the same
|
||||
version of Zulip as the server you're exporting from.
|
||||
|
||||
* For exports from Zulip Cloud (zulip.com), you need to [upgrade to
|
||||
- For exports from Zulip Cloud (zulip.com), you need to [upgrade to
|
||||
`main`][upgrade-zulip-from-git], since we run run `main` on
|
||||
Zulip Cloud:
|
||||
|
||||
@@ -315,7 +315,7 @@ archive of all the organization's uploaded files.
|
||||
zulip.com runs pre-release versions of Zulip that are often
|
||||
several months of development ahead of the latest release.
|
||||
|
||||
* Note that if your server has limited free RAM, you'll want to
|
||||
- Note that if your server has limited free RAM, you'll want to
|
||||
shut down the Zulip server with `./scripts/stop-server` while
|
||||
you run the import, since our minimal system requirements do not
|
||||
budget extra RAM for running the data import tool.
|
||||
@@ -326,10 +326,10 @@ new server to reuse the server-level configuration and secret keys
|
||||
from your old server. There are a few important details to understand
|
||||
about doing so:
|
||||
|
||||
* Copying `/etc/zulip/settings.py` and `/etc/zulip/zulip.conf` is
|
||||
- Copying `/etc/zulip/settings.py` and `/etc/zulip/zulip.conf` is
|
||||
safe and recommended. Care is required when copying secrets from
|
||||
`/etc/zulip/zulip-secrets.conf` (details below).
|
||||
* If you copy `zulip_org_id` and `zulip_org_key` (the credentials
|
||||
- If you copy `zulip_org_id` and `zulip_org_key` (the credentials
|
||||
for the [mobile push notifications
|
||||
service](../production/mobile-push-notifications.md)), you should
|
||||
be very careful to make sure the no users had their IDs
|
||||
@@ -345,15 +345,15 @@ about doing so:
|
||||
simply to not copy these settings and re-register your server for
|
||||
mobile push notifications if any users had their IDs renumbered
|
||||
during the logical export/import process.
|
||||
* If you copy the `rabbitmq_password` secret from
|
||||
- If you copy the `rabbitmq_password` secret from
|
||||
`zulip-secrets.conf`, you'll need to run
|
||||
`scripts/setup/configure-rabbitmq` to update your local RabbitMQ
|
||||
installation to use the password in your Zulip secrets file.
|
||||
* You will likely want to copy `camo_key` (required to avoid
|
||||
- You will likely want to copy `camo_key` (required to avoid
|
||||
breaking certain links) and any settings you added related to
|
||||
authentication and email delivery so that those work on your new
|
||||
server.
|
||||
* Copying `avatar_salt` is not recommended, due to similar issues
|
||||
- Copying `avatar_salt` is not recommended, due to similar issues
|
||||
to the mobile push notifications service. Zulip will
|
||||
automatically rewrite avatars at URLs appropriate for the new
|
||||
user IDs, and using the same avatar salt (and same server URL)
|
||||
@@ -421,8 +421,8 @@ delete the test import data from your Zulip server before doing a
|
||||
final import. You can **permanently delete** all data from a Zulip
|
||||
organization using the following procedure:
|
||||
|
||||
* Start a [Zulip management shell](../production/management-commands.html#manage-py-shell)
|
||||
* In the management shell, run the following commands, replacing `""`
|
||||
- Start a [Zulip management shell](../production/management-commands.html#manage-py-shell)
|
||||
- In the management shell, run the following commands, replacing `""`
|
||||
with the subdomain if [you are hosting the organization on a
|
||||
subdomain](../production/multiple-organizations.md):
|
||||
|
||||
|
||||
Reference in New Issue
Block a user