mirror of
https://github.com/zulip/zulip.git
synced 2025-11-03 05:23:35 +00:00
docs: Format Markdown with Prettier.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
(cherry picked from commit a4dbc1edd4)
This commit is contained in:
Anders Kaseorg
committed by
Tim Abbott
Tim Abbott
parent
aa6e70382d
commit
d81ce3ba76
@@ -65,6 +65,7 @@ su zulip -c '/home/zulip/deployments/current/manage.py backup'
|
||||
```
|
||||
|
||||
The backup tool provides the following options:
|
||||
|
||||
- `--output=/tmp/backup.tar.gz`: Filename to write the backup tarball
|
||||
to (default: write to a file in `/tmp`). On success, the
|
||||
console output will show the path to the output tarball.
|
||||
@@ -160,12 +161,12 @@ included in the backups generated by Zulip's standard tools. The
|
||||
data includes:
|
||||
|
||||
- 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
|
||||
30 days in S3. If you have an Amazon S3 bucket you wish to store for
|
||||
storing the backups, edit `/etc/zulip/zulip-secrets.conf` on the
|
||||
PostgreSQL server to add:
|
||||
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
|
||||
30 days in S3. If you have an Amazon S3 bucket you wish to store for
|
||||
storing the backups, edit `/etc/zulip/zulip-secrets.conf` on the
|
||||
PostgreSQL server to add:
|
||||
|
||||
```ini
|
||||
s3_backups_key = # aws public key
|
||||
@@ -180,17 +181,17 @@ PostgreSQL server to add:
|
||||
`/usr/lib/nagios/plugins/zulip_postgresql_backups/check_postgresql_backup`.
|
||||
|
||||
- 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.
|
||||
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/`.
|
||||
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
|
||||
user-uploaded avatars will need to be re-uploaded (since avatar
|
||||
filenames are computed using a hash of `avatar_salt` and user's
|
||||
email), etc.
|
||||
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
|
||||
user-uploaded avatars will need to be re-uploaded (since avatar
|
||||
filenames are computed using a hash of `avatar_salt` and user's
|
||||
email), etc.
|
||||
|
||||
[export-import]: ../production/export-and-import.md
|
||||
|
||||
@@ -258,17 +259,17 @@ before exporting; so that nobody can send new messages (etc.) while
|
||||
you're exporting data. There are two ways to do this:
|
||||
|
||||
1. `./scripts/stop-server`, which stops the whole server. This is
|
||||
preferred if you're not hosting multiple organizations, because it has
|
||||
no side effects other than disabling the Zulip server for the
|
||||
duration.
|
||||
preferred if you're not hosting multiple organizations, because it has
|
||||
no side effects other than disabling the Zulip server for the
|
||||
duration.
|
||||
1. Pass `--deactivate` to `./manage export`, which first deactivates
|
||||
the target organization, logging out all active login sessions and
|
||||
preventing all accounts from logging in or accessing the API. This is
|
||||
preferred for environments like Zulip Cloud where you might want to
|
||||
export a single organization without disrupting any other users, and
|
||||
the intent is to move hosting of the organization (and forcing users
|
||||
to re-log in would be required as part of the hosting migration
|
||||
anyway).
|
||||
the target organization, logging out all active login sessions and
|
||||
preventing all accounts from logging in or accessing the API. This is
|
||||
preferred for environments like Zulip Cloud where you might want to
|
||||
export a single organization without disrupting any other users, and
|
||||
the intent is to move hosting of the organization (and forcing users
|
||||
to re-log in would be required as part of the hosting migration
|
||||
anyway).
|
||||
|
||||
We include both options in the instructions below, commented out so
|
||||
that neither runs (using the `# ` at the start of the lines). If
|
||||
@@ -298,8 +299,9 @@ archive of all the organization's uploaded files.
|
||||
## Import into a new Zulip server
|
||||
|
||||
1. [Install a new Zulip server](../production/install.md),
|
||||
**skipping Step 3** (you'll create your Zulip organization via the data
|
||||
import tool instead).
|
||||
**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
|
||||
version of Zulip as the server you're exporting from.
|
||||
|
||||
@@ -321,10 +323,10 @@ archive of all the organization's uploaded files.
|
||||
budget extra RAM for running the data import tool.
|
||||
|
||||
2. If your new Zulip server is meant to fully replace a previous Zulip
|
||||
server, you may want to copy some settings from `/etc/zulip` to your
|
||||
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:
|
||||
server, you may want to copy some settings from `/etc/zulip` to your
|
||||
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
|
||||
safe and recommended. Care is required when copying secrets from
|
||||
@@ -361,8 +363,8 @@ about doing so:
|
||||
avatar image improperly for users whose ID was renumbered.
|
||||
|
||||
3. Log in to a shell on your Zulip server as the `zulip` user. Run the
|
||||
following commands, replacing the filename with the path to your data
|
||||
export tarball:
|
||||
following commands, replacing the filename with the path to your data
|
||||
export tarball:
|
||||
|
||||
```bash
|
||||
cd ~
|
||||
@@ -408,6 +410,7 @@ recommend starting with sending one to yourself for testing:
|
||||
```
|
||||
|
||||
and then once you're ready, you can email them to everyone using e.g.
|
||||
|
||||
```bash
|
||||
./manage.py send_password_reset_email -r '' --all-users
|
||||
```
|
||||
@@ -434,6 +437,7 @@ realm.delete()
|
||||
The output contains details on the objects deleted from the database.
|
||||
|
||||
Now, exit the management shell and run this to clear Zulip's cache:
|
||||
|
||||
```bash
|
||||
/home/zulip/deployments/current/scripts/setup/flush-memcached
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user