简体中文
备份与恢复
应同时采用两层备份：配置导出便于迁移，而要恢复运行历史和媒体文件则必须进行文件系统快照。
各类备份包含什么
| 备份 | 包含 | 不包含 |
|---|---|---|
| 设置 > 备份与恢复导出 | 全局设置、模板、主播及过滤器、引擎、平台设置、通知渠道/订阅、任务与管道预设、用户和密码哈希、凭据配置和选择策略、已保存的代理及其登录信息和各作用域的代理设置 | 录制媒体、会话/任务历史、日志、刷新令牌会话 |
| 文件系统备份 | 实际复制的 DATA_DIR、CONFIG_DIR、OUTPUT_DIR，以及可选 LOG_DIR | 外部上传目标和通知服务中的数据 |
敏感导出
配置导出可能包含平台 Cookie、凭据刷新/访问令牌及重新登录材料、代理用户名和密码、通知凭据、渠道设置、用户信息和密码哈希。必须加密、限制访问，且不要附加到公开 Issue。
配置导出
在 Web 界面打开设置 > 备份与恢复并下载导出文件。对应 API 为 GET /api/config/backup/export 和 POST /api/config/backup/import。
过滤器和通知订阅按每批最多 500 个所属实体查询，保持主播/渠道顺序和各实体原有的 子项顺序。批量读取失败时，后端会逐个重试该批实体，使其他正常实体的数据仍能 保留在导出中。与此前相同，关联数据查询仍然失败的实体会带有空的过滤器/订阅列表； 后端会记录恢复和失败数量。主要配置列表读取失败时，导出仍会中止。
导入支持两种模式：
merge更新匹配实体，并保留文件中没有的现有实体。replace删除导入文件未包含的现有受管配置。该操作具有破坏性，应先在临时实例验证。
对于结构版本为 0.1.3 或更高且用户列表非空的导出文件，用户按用户名匹配。 导入会在任何配置写入之前，根据最终用户集合检查邮箱唯一性，包括 merge 模式保留的账号。邮箱比较保留大小写和空白：User@example.com 与 user@example.com 被视为不同值。空字符串也必须唯一；多个用户可以不设置邮箱（null）。
导入可以交换两个待更新用户的邮箱，也可以把某个待更新用户释放的邮箱分配给另一个用户。 replace 模式还可以复用被省略用户的邮箱。用户名匹配的现有用户会保留 ID 和创建时间。 如果后续任意导入写入失败，邮箱改动会与其他配置写入一起回滚。 省略用户列表、用户列表为空或结构版本早于 0.1.3 时，两种模式都会保留现有用户。
每次成功导入都会撤销全部刷新令牌及其绑定的访问令牌会话，包括省略用户的 merge 导入。导入完成后请重新登录。 被拒绝的导入不会撤销令牌。
配置导出适合迁移；移除密钥后也可用于版本审查，但它不是数据库备份。
配置导入使用一个数据库事务。提交前的校验或写入失败不会修改配置；提交后的重载警告表示配置已保存，但运行时刷新仍需处理。
一致的文件系统备份
标准 Docker 布局可按以下流程操作：
- 下载一份最新配置导出。
- 禁止新录制任务或安排维护窗口。
- 执行
docker compose stop，确保 SQLite 和活跃媒体文件一致。 - 快照或复制
DATA_DIR、CONFIG_DIR、OUTPUT_DIR、.env和docker-compose.yml。只有事件保留政策要求时才备份LOG_DIR。 - 执行
docker compose up -d，并验证存活检查。
systemd 服务的流程相同，只是换成 unit 自己的路径：
- 下载一份最新配置导出。
- 禁止新录制任务或安排维护窗口。
- 执行
systemctl stop rust-srec，确保 SQLite 和活跃媒体文件一致。 - 快照或复制
/var/lib/rust-srec（数据库、WAL 文件和默认输出目录）、/etc/rust-srec/rust-srec.env，以及ReadWritePaths=中列出的录制卷。只有事件保留政策要求时才备份/var/log/rust-srec。 - 执行
systemctl start rust-srec，并验证存活检查。
.env、/etc/rust-srec/rust-srec.env 和备份媒体的保护强度不得低于在线服务。至少保留一份主机外备份，并定期校验完整性。
恢复演练
- 准备空间充足的干净主机，并使用同一固定 Rust-Srec 版本。
- 保持服务停止，把目录恢复到相同绝对路径，并恢复所有权和权限。
- 恢复
.env与 Compose 配置，或恢复/etc/rust-srec/rust-srec.env与 unit 文件。等价恢复时不要重新生成JWT_SECRET，除非有意让全部访问令牌失效。 - 启动服务并检查
/api/health/live。 - 登录后检查带认证的
/api/health/ready，核对主播和会话，并播放或校验代表性媒体。 - 用一个非关键频道测试录制和管道。
会话可以比它所属的主播存在得更久：live_sessions.streamer_id 允许为空，删除主播时会保留会话、媒体记录和会话上保存的主播名。因此恢复出的数据库中出现找不到对应主播的会话是正常现象，并不说明恢复有问题。
记录恢复耗时和实际丢失的数据时间范围；这才是你的真实 RTO 和 RPO。
此节内容已移至持久化约定.
凭据配置与回滚
没有凭据配置、选择策略和已保存代理的导出保留 0.1.8。只要存在凭据配置或显式选择策略，就使用 1.0.0，即使策略仅为 inherit 或 none、没有账号也一样。旧版导入器会拒绝该版本。这是备份格式版本，不是应用版本。过滤导出必须保留引用的凭据及其平台；不完整的凭据关系会被拒绝。凭据配置包含 Cookie、刷新/访问令牌及支持的重新登录材料，须按数据库同等标准保护。
未被占用的凭据 UUID 会保留；已有 UUID 只有属于同一平台时才更新，否则整次导入失败。不会按名称或 Cookie 内容猜测账号。凭据配置按平台名对应到平台，重复导入更新同一账号。凭据引用校验及所有配置写入共用一个事务。
来自在配置中保存 Cookie 的旧版本的备份，导入时按与升级相同的规则转换：其中的 Cookie、令牌和登录信息会成为凭据配置，并由导入的作用域选中。备份的格式版本保持不变，其他字段仍按原方式读取。
合并模式保留文件中省略的凭据及选择策略；重置选择请显式使用 inherit。替换模式将省略的凭据及被移除的所有者标记为待清理，提交后停止受影响的录制，等活动会话结束才物理删除材料。HTTP 客户端断开不会阻止已提交配置发布到运行时。恢复的材料获得新修订号，旧刷新结果不能覆盖它，后续下载尝试重新获取媒体。托管凭据健康状态、限流暂停、轮询位置、会话绑定、二维码回执及播放上下文均不属于配置备份。
升级前请创建一致的数据库备份；升级会把配置中的 Cookie 迁移到凭据配置。直接用旧二进制打开升级后的数据库不是受支持的回滚方式：旧版本可能拒绝迁移版本，也无法解释托管策略。应同时恢复升级前的数据库备份和对应旧二进制。账号池无法无损降级为单 Cookie 导出。
备份中的代理
1.0.0 格式的导出包含每个已保存的代理及其名称、地址、用户名和密码，以及各作用域和账号的代理设置；设置按代理名称而不是 ID 引用代理。没有账号、选择策略和已保存代理的导出保留 0.1.8，并以旧格式写出全局、平台、模板和主播的设置，供早期版本读取：直连 写为关闭的代理，系统代理 写为使用系统代理选项。
导入时，备份中的每个代理先按名称匹配，名称不匹配时再按地址和用户名匹配，匹配到就更新该代理，否则新建，然后才写入选用它的设置。设置引用的代理既不在备份中也不在服务器上时，整次导入会被拒绝。合并模式保留备份中省略的已保存代理，备份未给出代理设置的作用域保留原设置。替换模式会把这类作用域改为继承（全局设置除外），并删除备份中省略且已无任何设置使用的代理；仍在使用的代理会保留。恢复的代理地址或用户名有变化时，等同于修改了选用它的账号的凭据，这些账号会重新检查。
来自保存代理功能推出之前版本的备份，导入时按与升级相同的规则转换，但不参考服务器的环境变量：关闭的全局代理会变为 直连。服务器上已保存的相同地址和用户名会复用该代理并保留其密码；新建的代理使用尚未被占用的名称。