Zulip 备份、导出与导入全指南：从整机恢复、组织迁移到合规导出

Zulip 备份、导出与导入全指南从整机恢复、组织迁移到合规导出【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulipZulip 提供了两套互为补充的高质量数据工具备份Backup工具用于精确恢复整个 Zulip 服务器的运行状态灾备恢复、硬件迁移、生产数据测试而逻辑数据导出Data Export工具用于在 Zulip Cloud 与自托管服务器之间迁移组织、以及各类审计与合规场景。本文以docs/production/export-and-import.md为主线结合仓库源码zerver/management/commands/backup.py、scripts/setup/restore-backup、zerver/lib/export.py、zerver/management/commands/export_search.py等逐层拆解读完你将掌握备份的创建与恢复、组织的导出与导入、合规检索导出以及基于 wal-g 的连续时间点数据库备份方案并理解每一步背后的实现原理与适用边界。工具选型先分清“备份”与“导出”的适用场景在动手之前必须先理解 Zulip 中“备份”与“逻辑导出”是两类目的截然不同的工具选错会导致不必要的用户干扰或数据形态不匹配。备份工具Backup的设计目标是精确还原一台 Zulip 服务器的状态适合灾难恢复、使用生产数据做测试、硬件迁移等场景。官方强烈推荐在适用场景下优先使用它因为快速、健壮对用户的中断最小产出的是一个包含数据库、配置、密钥、上传文件的.tar.gz归档还原后服务器即恢复原状。但备份工具有如下限制备份必须恢复到运行相同 Zulip 版本的服务器上精确地说是manage.py showmigrations输出完全一致的版本备份必须恢复到相同 PostgreSQL 版本的服务器上。安装时可通过--postgresql-version参数详见 部署文档中的安装器选项指定与备份时一致的 PostgreSQL 版本。注意 PostgreSQL 可以独立于 Zulip 其余部分进行升级备份不适合在自托管与 Zulip Cloud 之间迁移组织这种迁移可能需要对所有用户/消息等重新编号。逻辑数据导出工具Data Export的设计目标是在 Zulip Cloud 与其他 Zulip 服务器之间迁移数据以及各类审计用途。推荐在备份工具不适用时使用它尤其是需要易于机器解析的导出格式时。它的限制与注意事项与备份工具类似逻辑导出也必须在相同 Zulip 版本的服务器上导入但逻辑导出可以导入到PostgreSQL 版本不同、或托管着不同组织集合的服务器上通过导出工具转移组织会带来显著的用户可见中断所有用户会被登出账号并要求重置密码。逻辑导出工具产出一个.tar.gz归档其中大部分 Zulip 数据库数据以 JSON 文件编码——这一格式与 Zulip 面向第三方服务如 Slack的数据导入工具共用。此外 Zulip 生态还包含合规导出Compliance exports允许服务器管理员按搜索条件导出消息详见下文专属小节HTML 归档工具zulip-archive独立仓库主要用于公开归档也可在解散组织时以低成本保留公开频道对话高可用环境可组合使用 PostgreSQL 流式复制 与 S3 文件上传后端 搭建高可用架构。需要说明的是本文所有命令均针对标准的 tar.gz 自托管安装。若你使用 Docker 部署推荐的备份单元是包含近期app:backup数据库转储的/data卷快照manage.py backup工具虽也支持 Docker 与标准安装之间的双向迁移但不是Docker 部署日常备份的推荐方式。备份工具一条命令打包整台服务器Zulip 服务器内置了备份命令以zulip用户身份执行# 以 zulip 用户身份 /home/zulip/deployments/current/manage.py backup # 或作为 root su zulip -c /home/zulip/deployments/current/manage.py backup该命令支持的选项与源码 zerver/management/commands/backup.py 中的add_arguments完全对应选项说明--output/tmp/backup.tar.gz指定备份 tarball 的输出文件名默认写入/tmp下的文件。成功时控制台会输出 tarball 路径--skip-db跳过数据库备份。适用于使用自带备份体系的远程 PostgreSQL 主机只需备份非数据库状态时--skip-uploads若设置了LOCAL_UPLOADS_DIR忽略该目录下用户上传的文件执行后会生成一个.tar.gz归档包含在另一台机器上完美还原 Zulip 服务器状态所需的全部数据。从源码看备份归档是如何组装的阅读 zerver/management/commands/backup.py 的实现可以发现几个值得注意的细节版本标识文件归档内会写入zulip-backup/zulip-version来自version.py的ZULIP_VERSION若为 git 部署还会追加try_git_describe()的版本描述、zulip-backup/os-version来自platform.freedesktop_os_release()形如ID VERSION_ID与zulip-backup/postgres-version来自 PostgreSQL 的server_version。这正是后文“检查备份归档”一节中读取这些文件的来源。数据库转储方式使用/usr/lib/postgresql/major_version/bin/pg_dump以--formatdirectory目录格式导出并自动注入settings.DATABASES[default]中的用户名、库名、主机与端口通过环境变量PGPASSWORD传入密码。配置与密钥生产环境下打包整个/etc/zulipsettings.py、zulip-secrets.conf等开发环境下则打包zproject/目录。上传文件仅当LOCAL_UPLOADS_DIR已配置且目录存在时才将该目录纳入归档配合--skip-uploads跳过。打包过程使用tar -cPhzf生成内部通过--transform规则把上述路径统一映射到zulip-backup/前缀下方便恢复脚本按固定布局解包。恢复备份恢复备份的标准流程安装与备份时相同的基础操作系统。若之后想升级操作系统应在恢复完成后再进行。安装一台新的 Zulip 服务器进行到安装流程的 Step 3 为止通过--postgresql-version参数安装与备份时相同版本的 PostgreSQL。若之后想升级 PostgreSQL 版本应在恢复完成后再进行。安装指南见 install.md。以 root 身份导入备份/home/zulip/deployments/current/scripts/setup/restore-backup /path/to/backup完成后Zulip 服务器应完全恢复运行。更换主机名测试恢复时的常见场景测试恢复备份时为避免干扰线上服务常用与原始服务器不同的对外主机名例如用zuliptest.example.com代替zulip.example.com。此时和任何一次修改主机名一样需要更新 EXTERNAL_HOST 配置 并在备份恢复完成后重启 Zulip 服务器。否则服务器仍认为其对外主机名是zulip.example.com通过zuliptest.example.com访问时会返回 HTTP400 BAD REQUEST。修改数据库设置如果目标是一台配置差异很大的主机例如REMOTE_POSTGRES_HOST指向不同值可先编辑/etc/zulip/settings.py适配新主机再用--keep-settings恢复/home/zulip/deployments/current/scripts/setup/restore-backup --keep-settings /path/to/backup若还想保留本机的/etc/zulip/zulip.conf可追加--keep-zulipconf参数。检查备份归档内容如果不确定某份备份创建时的版本信息可以直接读取归档内的postgres-version、os-version和zulip-version三个文件无需解包整个归档tar -Oaxf /path/to/archive/zulip-backup-rest.tar.gz zulip-backup/zulip-version恢复脚本做了什么restore-backup 源码解析恢复入口是 scripts/setup/restore-backupPython 脚本其内部流程与manage.py backup正好对称要求以 root 运行随后su_to_zulip(save_suidTrue)切换身份先把归档中的zulip-backup/settings即/etc/zulip的配置解包到/etc/zulip——这样后续才能加载真实配置--keep-settings与--keep-zulipconf分别通过--excludesettings.py、--excludezulip.conf实现依据配置确定LOCAL_UPLOADS_DIR与zproject/开发环境路径并解包上传文件重建数据库调用terminate-psql-sessions终止现存会话、dropdb --if-exists删除旧库、createdb --ownerzulip --templatetemplate0创建全新空库生产环境下依次执行generate_secrets.py兼容旧版本备份缺失的新密钥、configure-rabbitmq当RABBITMQ_HOST为本地地址时同步 RabbitMQ 密码与zulip-secrets.conf、zulip-puppet-apply -f应用zulip.conf中记录的配置用pg_restore恢复数据库——注释特别说明它必须放在zulip-puppet-apply之后以确保全文检索扩展已安装可用生产环境执行scripts/restart-server最后flush-memcached刷新缓存。备份包含什么、不包含什么备份包含完整还原 Zulip 服务器所需的全部内容数据库、设置、/etc/zulip中的密钥、以及存储在服务器上的用户上传文件。以下数据不包含在备份归档中需要你另行备份服务器访问/错误日志/var/log/zulip。Zulip 服务器只追加日志其体积可能远超其他数据。通过 Zulip S3 上传后端 上传的文件。原因有二S3 中的上传文件体积可能比备份其余部分大出数倍下载到备份服务器可能超出其磁盘容量且 S3 本身是可靠的持久存储自带高质量备份工具。SSL 证书。证书尤其敏感要么可由 Certbot 轻松重新生成要么由系统管理员自行提供。另外备份也不包含 Zulip 不存入数据库的高度瞬时状态例如输入状态数据、API 限流计数器、以及健康服务器上基本恒空的 RabbitMQ 队列如待发送邮件。可用rabbitmqctl list_queues检查这些队列是否为空。在 Docker 部署中包含清单有所不同——备份单元是/data卷而非manage.py backuptarball详见 Docker 部署文档 中的卷布局与快照方案。手动备份细节Backup details本节主要面向自行管理备份的管理员例如使用远程 PostgreSQL 且已有备份策略同时也说明了 Zulip 标准工具生成的备份究竟包含哪些数据PostgreSQL 数据库可用任何标准数据库导出/备份工具备份Zulip 对持续时间点备份的内置支持见下文“仅数据库备份工具”。任何用户上传文件若使用 S3 存储上传文件则由 S3 负责备份若设置了LOCAL_UPLOADS_DIR用户上传的所有文件包括头像会存放在该目录需要你备份它。/etc/zulip/下的 Zulip 配置含密钥。举例说明其重要性若丢失secret_key替换服务器上将无法校验用户 Cookie所有用户都必须重新登录若丢失avatar_salt所有用户上传的头像都需要重新上传因为头像文件名是由avatar_salt与用户邮箱的哈希计算得出的以此类推。从手动备份恢复若你之前是手动备份而非manage.py backup恢复流程基本是上述过程的逆向操作按常规方式下载 Zulip 发布 tarball 并运行scripts/setup/install安装新服务器务必传入--no-init-db因为我们不需要创建新数据库从备份中把settings.py与zulip-secrets.conf解包到/etc/zulip从备份中恢复数据库以 root 运行scripts/setup/configure-rabbitmq让 RabbitMQ 使用secrets.conf中的密码若使用本地文件上传将文件恢复到settings.LOCAL_UPLOADS_DIR指定的路径以及合适的话恢复日志用scripts/restart-server启动服务器。这套恢复流程也可用于把 Zulip 安装迁移到另一台服务器。官方建议在配置好备份后进行一次灾难恢复演练以确认备份确实可用。逻辑数据导出把整个组织搬去新服务器Zulip 的数据导出工具专为在不同 Zulip 安装之间迁移组织而设计因此这类导出包含一个 Zulip 组织的全部非瞬时数据唯一例外是密钥类信息如密码和 API key。在适用场景下官方仍推荐优先使用备份工具因为数据导出流程相对有以下缺点所有用户的密码会被随机化、并被登出账户Web 与移动端均如此所有机器人bot与集成都需要更新新的 API key用户、频道、消息通常会被重新编号外部程序引用这些对象的链接大多会失效。导出前考虑升级官方建议在导出前把服务器升级到最新维护版本至少是本大版本的最新维护版。针对导入 Zulip Cloud 的场景若你从自托管服务器导出数据、准备导入 Zulip Cloud应先把服务器升级到zulip-cloud-current分支/home/zulip/deployments/current/scripts/upgrade-zulip-from-git zulip-cloud-current仅停留在最新稳定版是不够的——Zulip Cloud 运行的是预发布版本往往领先最新发布版数月开发进度。该命令对应的升级机制详见 upgrade.md 中“从 git 仓库升级”。导出期间防止数据变更为了获得最佳结果导出前应关闭对组织的访问避免导出过程中有人发送新消息等。有两种方式./scripts/stop-server停止整台服务器。若你没有托管多个组织这是首选——除在持续时间内禁用 Zulip 服务器外没有任何副作用。给./manage export传--deactivate先停用目标组织登出所有活跃登录会话并阻止所有账户登录或访问 API。这适合 Zulip Cloud 这类环境只想导出单个组织而不干扰其他用户且本意就是转移该组织的托管迁移托管本来也要求用户重新登录。下方导出命令中两种选项都以#注释形式给出需要时去掉对应行的#即可。执行导出以zulip用户登录服务器 shell运行cd /home/zulip/deployments/current # ./scripts/stop-server # export DEACTIVATE_FLAG--deactivate # 停用该组织 ./manage.py export -r $DEACTIVATE_FLAG # 导出数据-r用于指定要导出的组织表示托管在 Zulip 服务器根域名的默认组织。命令会生成一个形如/tmp/zulip-export-2026-05-25-09-30-45-zcmpxfm6.tar.gz的压缩归档内含多个 JSON 文件组织的 Zulip 数据以及组织全部上传文件的归档。导出命令的更多选项与源码实现从 zerver/management/commands/export.py 的add_arguments可以看到除了-r与--deactivate该命令还支持选项说明--output dir指定导出数据写入的目录默认在临时目录创建--parallel N并行导出 UserMessage 的进程数默认取settings.DEFAULT_DATA_EXPORT_IMPORT_PARALLELISM--public-only只导出公开频道消息及关联附件--export-full-with-consent导出已同意用户的私密数据与--public-only互斥--upload导出完成后把 tarball 上传到 S3 或LOCAL_UPLOADS_DIR其help文本清晰列出了导出内容与不导出内容导出所有用户可访问的数据库数据消息、频道、UserMessage、RealmEmoji 等与上传文件/头像及还原所需元数据不导出确认码与预注册用户表瞬时表、会话导出后人人需重新登录、用户密码与 API key需 SSO 或重置密码、APNS/GCM 移动推送令牌、ScheduledEmail、RemoteZulipServer以及第三方 API 结果缓存。同时也提示了导出后的影响密码不会迁移、桌面端/移动端需重新登录、所有 bot 因服务器 URL 与 API key 变更而需重新配置。底层导出由 zerver/lib/export.py 驱动export.py命令会创建一条RealmExport记录状态依次为 REQUESTED → STARTED → SUCCEEDED异常时为 FAILED再调用export_realm_wrapper()内部执行do_export_realm()完成后计算并打印 tarball 的SHA-256 校验和与字节大小并写入RealmAuditLog事件类型REALM_EXPORTED若传了--upload还会调用upload_export_tarball()上传并输出公开 URL。归档命名前缀由export_tarball_prefix(realm)生成即zulip-export-string_id-时间戳-与文档中的示例文件名一致。若导出时传了--deactivate命令会先通过do_deactivate_realm(..., deactivation_reasonself_hosting_migration, email_ownersFalse)停用组织而导出的数据仍会以“组织处于活跃状态”的形式呈现export_as_activeTrue。导入到新的 Zulip 服务器安装一台新的 Zulip 服务器跳过 Step 3你的 Zulip 组织将通过数据导入工具创建。确保导入目标服务器的 Zulip 版本与导出源服务器相同。若导出来自 Zulip Cloudzulip.com需要先升级到zulip-cloud-current即 Zulip Cloud 当前运行的版本通常是main延迟一到两周/home/zulip/deployments/current/scripts/upgrade-zulip-from-git zulip-cloud-current仅停留在最新稳定版不够——zulip.com 运行的预发布版本往往领先最新发布版数月。若服务器可用内存有限导入期间建议先./scripts/stop-server停掉 Zulip 服务器因为官方最低系统需求并未为运行数据导入工具预留额外内存。如果新服务器将完全取代旧服务器复制/etc/zulip/settings.py与/etc/zulip/zulip.conf是安全且推荐的可避免重复配置工作。 复制/etc/zulip/zulip-secrets.conf同样安全且推荐但有以下重要例外与注意事项不建议复制avatar_salt。Zulip 会自动按新用户 ID 重写合适 URL 的头像导入后仍用相同 avatar salt且服务器 URL 相同可能因浏览器缓存导致 ID 被重新编号的用户头像显示异常。推荐复制zulip_org_id与zulip_org_key以免服务器与 移动推送通知服务 的注册断开。若复制了zulip-secrets.conf中的rabbitmq_password需要以 root 运行scripts/setup/configure-rabbitmq让本地 RabbitMQ 使用 secrets 文件中的密码。复制camo_key是必须的否则消息里指向外部托管图片的链接会失效。若服务器是早于 Zulip 5.0 的旧版本、且使用移动推送通知服务应尽可能在导出/导入前升级并视需要联系官方支持。以zulip用户登录服务器 shell把文件名替换为你的导出 tarball 路径运行cd ~ tar -xf /path/to/export/file/zulip-export-2026-05-25-09-30-45-zcmpxfm6.tar.gz cd /home/zulip/deployments/current ./manage.py import ~/zulip-export-2026-05-25-09-30-45-zcmpxfm6 ./scripts/start-server导入耗时取决于数据量可能长达数分钟。导入选项子域名与更多参数上述命令把导入的组织创建在 Zulip 安装的根域名EXTERNAL_HOST下。如果你希望在自定义子域名下导入例如根域名已存在组织把最后两行替换为./manage.py import subdomain ~/zulip-export-2026-05-25-09-30-45-zcmpxfm6 ./scripts/start-server其中subdomain换成想要的子域名。从 zerver/management/commands/import.py 的源码看import命令还支持--destroy-rebuild-database导入前销毁并重建数据库内部调用 Djangoflush与scripts/setup/flush-memcached--import-into-nonempty导入到已非空的数据库源码注释表明这已是默认行为--allow-reserved-subdomain允许使用保留子域名--processes N并行上传头像到 S3 的进程数默认同样取DEFAULT_DATA_EXPORT_IMPORT_PARALLELISM命令接受多个导出目录export_paths为nargs可一次导入多个导出导入前会校验目录存在、子域名可用并提示“若是 tarball 请先解包”。导入后登录导入完成后所有用户都在新组织中拥有账户但这些账户还没有密码出于安全考虑密码不导出。用户要么通过 Google auth 等方式认证要么从重置密码开始。可使用./manage.py send_password_reset_email向用户发送密码重置邮件。建议先给自己发一封测试./manage.py send_password_reset_email -u usernameexample.com准备就绪后再向所有人发送例如./manage.py send_password_reset_email -r --all-users使用子域名时把换成你的子域名。删除测试导入与重新导入如果做过一次测试导入你可能希望在最终导入前删除测试数据。可用以下命令永久删除一个 Zulip 组织的全部数据若在子域名托管组织把换成子域名./manage.py delete_realm -r 假设使用本地文件上传后端还可删除服务器上所有组织的文件上传、头像与自定义表情rm -rf /home/zulip/uploads/*/*若托管多个组织、只想删除单个组织的上传需要在删除数据库中的组织前在管理 shell 中取得realm.idZulip 服务器上第一个创建的组织为2见下例rm -rf /home/zulip/uploads/*/2/完成后即可重新运行导入流程。命令实现见 zerver/management/commands/delete_realm.py。合规导出按检索条件导出消息某些情况下公司或法律合规要求进行选择性数据导出。这可以通过export_search命令行工具完成导出消息时可指定以下参数消息文本中的搜索关键词消息的发送者或接收者消息发送的时间范围。例如搜索aliceexample.com在 11 月 1 日至 6 日之间发送的、包含 wonderland 一词的消息$ /home/zulip/deployments/current/manage.py export_search --output compliance-export.json \ -r zulip \ --after 2022-11-01 00:00:00 --before 2022-11-06 14:00:00 \ --sender aliceexample.com \ wonderland结果写入 JSON 或 CSV 文件。已编辑消息的旧版本内容不会被搜索到已删除消息也不会。与结果消息关联的附件可选地一并导出。更多支持的选项参见/home/zulip/deployments/current/manage.py export_search --help。源码视角export_search 的过滤与输出实现从 zerver/management/commands/export_search.py 可以看到完整参数面与实现关键词匹配对消息content做icontains不区分大小写包含匹配频道消息同时匹配subject主题/话题关键词既可通过位置参数传入也可用--file path从文件按行读取时间过滤--after/--before接收 ISO 格式 datetime统一按 UTC 处理源码中datetime.fromisoformat(...).astimezone(timezone.utc)分别映射为date_sent__gt/date_sent__lt人员过滤互斥组--sender按发件邮箱iexact匹配、--recipient通过 UserMessage 判断某用户是否收到可多次指定是--sender的超集、--dm限定于给定用户集合之间的私信1 人/2 人/多人三种分支分别处理、--channel按频道名限定输出格式--output必须以.json或.csv结尾默认拒绝覆盖已存在文件除非--force--write-attachments dir可把引用到的附件并行下载到指定目录默认 5 个线程--threads可调transform_message会输出消息 id、UTC 时间戳、发件人、收件人含频道#频道名 主题格式、内容与编辑历史有附件时附上path_id列表。仅数据库备份工具基于 wal-g 的连续时间点备份前面介绍的 Zulip 专用备份工具是完美的“一体化”备份方案适合每日夜间备份。若需要连续时间点备份Zulip 内置了每日备份快照 使用wal-g的流式预写日志WAL备份支持默认保留 30 天。注意这些数据库备份本身并不构成 Zulip 系统的完整备份系统级备份还需要上文“备份细节”一节中列出的其他部分配置、密钥、上传文件等。每日全量数据库备份在0200 UTC进行每份 WAL 归档文件在 PostgreSQL 保存时即被备份WAL 每写满 16KiB 生成一份。这意味着在低活跃时段备份可能需要几分钟才会写入 S3——可通过 PostgreSQL 的archive_timeout参数设置该时延的上限。如果需求是“始终最新”的备份可用性Zulip 还提供内置数据库复制支持。你应该也应该定期监控备份是否正常运行例如通过puppet/zulip/files/postgresql/wal-g-exporter中的 Prometheus 导出器。流式备份到 S3这提供了持久可靠的异地数据库备份官方建议采用此配置以抵御磁盘故障。由于备份随 WAL 写入实时进入 S3活跃的 Zulip 服务器每天会向 S3 发送大量 PutObject 请求可能每天数千次。编辑 PostgreSQL 服务器上的/etc/zulip/zulip-secrets.conf添加s3_region # 要写入 S3 的区域默认为 EC2 主机所在区域 s3_backups_key # aws 公钥可选如果不通过角色访问 s3_backups_secret_key # aws 密钥可选如果不通过角色访问 s3_backups_bucket # S3 备份桶名称运行/home/zulip/deployments/current/scripts/zulip-puppet-apply此外还可以调整并发数backups_disk_concurrency、S3 存储类别backups_storage_class与增量备份backups_incremental等配置均位于zulip.conf的[backups]相关配置项详见 system-configuration.md。流式备份到本地磁盘作为 S3 的替代方案也可以把备份存到本地磁盘。不建议用它做灾难恢复——除非该目录与数据库位于不同磁盘否则数据库丢失时备份通常也会一起丢失。此方案适合目录挂在 NAS 挂载点、或有其他进程把数据拷离磁盘、或备份仅用于近期应用层数据变更的时间点历史分析等场景。编辑 PostgreSQL 服务器上的/etc/zulip/zulip.conf在已有的[postgresql]段中添加# 调整为你想要的存储位置应放在与存放数据库的 /var/lib/postgresql/ 不同的磁盘上 backups_directory /srv/zulip-db-backups运行/home/zulip/deployments/current/scripts/zulip-puppet-apply同样可以调整增量备份配置。从 wal-g 备份恢复以下步骤从最新备份恢复数据库。注意该过程会删除你当前的数据库。以 root 身份在数据库主机上查看备份列表最新备份列在底部正是下面命令要恢复的env-wal-g backup-list --pretty若 Zulip 正在运行先停止它。在应用主机上取决于配置可能与数据库主机相同或不同/home/zulip/deployments/current/scripts/stop-server以 root 身份在数据库主机上停止 PostgreSQLservice postgresql stop以 root 身份在数据库主机上删除当前数据库并从备份恢复。耗时取决于数据库大小与到备份存储的连接pg_version$(crudini --get /etc/zulip/zulip.conf postgresql version) rm -rf /var/lib/postgresql/$pg_version/main env-wal-g backup-fetch /var/lib/postgresql/$pg_version/main LATEST chown -R postgres.postgres /var/lib/postgresql/$pg_version/main touch /var/lib/postgresql/$pg_version/main/recovery.signal service postgresql start其中的recovery.signal文件指示 PostgreSQL 以恢复模式启动重放备份后的 WAL 记录直至最新状态。以 root 身份在应用主机上刷新缓存并启动 Zulip/home/zulip/deployments/current/scripts/setup/flush-memcached /home/zulip/deployments/current/scripts/start-server实践建议小结日常灾备首选备份工具一条manage.py backup即可产出完整还原单元配合scripts/setup/restore-backup恢复务必在正式环境外做一次恢复演练并验证zulip-version/os-version/postgres-version三个版本标识与目标环境一致。跨环境/跨服务商迁移走逻辑导出manage.py export -r 导出 → 新服务器manage.py import导入导出前停服或--deactivate防止数据变更导入前核对 Zulip 版本Cloud 场景需zulip-cloud-current分支并按需复制/排除zulip-secrets.conf中的各项密钥。合规检索用export_search按关键词、时间、发件人/收件人/私信/频道精确圈定消息集输出 JSON/CSV可附带附件。高可用与时间点恢复叠加 wal-g在 PostgreSQL 主机配置 S3 或本地目录流式备份配合每日 0200 UTC 快照与 WAL 归档实现连续时间点恢复监控脚本位于puppet/zulip/files/postgresql/wal-g-exporter。【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考