企业官网建设流程全解析

自托管 SuperSync 服务器数据丢失后，怎么选择账号级恢复还是整库恢复？

【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity

你自托管了 Super Productivity 的 SuperSync 同步服务器（packages/super-sync-server），某天服务器宕机或数据库丢失，需要把服务恢复起来。此时第一个问题不是"怎么恢复"，而是"用哪条路径恢复"：只恢复账号（accounts-only restore），还是整库恢复（full database restore）。两条路径的操作成本、副作用和数据风险差别很大。

选择依据来自 SuperSync 的架构事实：它使用 append-only 操作日志做同步，每个客户端（桌面、移动端、Web）在本地 IndexedDB 中都持有完整数据副本，服务器只是中继，客户端才是数据的权威来源。因此只要还有一台客户端设备活着，数据就能恢复；服务器端只独有账号信息（邮箱、密码哈希）和 passkeys（WebAuthn 凭据），这些无法从别处重建。

前提：你已经配置了定期备份。备份由 backup.sh 生成两种 dump，存放在脚本目录旁的backups/目录：

• 全量 dump（supersync_*.sql.gz）——完整数据库，包含全部操作记录（活跃实例约 300MB+）；
• 仅账号 dump（supersync_accounts_*.sql.gz）——只有users和passkeys两张表（<1MB）。

恢复前先确认备份可用

在动任何数据之前，先按 backup-and-recovery.md 给出的方式验证备份文件存在且内容有效：

# 检查备份文件存在且大小合理 ls -lh backups/ # 确认 dump 是合法 SQL gunzip -c backups/supersync_YYYYMMDD_HHMMSS.sql.gz | head -5 # 如果配置了每日 cron，检查它确实在跑 cat /var/log/supersync-backup.log

YYYYMMDD_HHMMSS是备份文件的时间戳，替换为ls -lh backups/中实际选用的那一份（选最接近丢失时间的）。备份的默认保留期是 14 天（RETENTION_DAYS），超过保留期的文件会被脚本删除。

怎么选择：只问一个问题

文档给出的恢复决策树很直接：

服务器宕机 / 数据丢失 ├── 是否还有任何客户端设备持有数据？ │ ├── 是 → 用仅账号恢复（推荐） │ │ 客户端会自动重新上传数据 │ └── 否 → 用整库恢复（兜底） │ 接受自上次备份以来的数据丢失

• 至少一台客户端设备最近在线（本地仍有完整数据）→ 走仅账号恢复。这是文档明确标注的推荐路径，最简单也最可靠。
• 所有客户端设备都丢失，没有任何设备能重新上传数据 → 才走整库恢复，并接受自上次备份以来的数据丢失。

注意边界：如果只有某一个账号被清空（例如一次坏的SYNC_IMPORT把空快照或旧快照扩散到了该用户的设备），那是单用户回滚场景，不属于本文两条全服务器路径，文档将其单独列为 Per-User Recovery 处理，本文不展开。

路径一：仅账号恢复（推荐）

适用条件：至少一台客户端设备最近在线、仍持有数据。

原理：恢复后服务器的同步数据（operations、snapshots）从空开始。客户端重新连接时，gap detection 会自动触发，每台客户端把完整状态重新上传到服务器，所有客户端最终收敛到一致状态。

步骤（文档原样给出的全部操作，就一条命令）：

# 1. 从备份恢复账号（users + passkeys） gunzip -c backups/supersync_accounts_YYYYMMDD_HHMMSS.sql.gz | \ docker exec -i supersync-postgres psql -U supersync supersync # 2. 完成 —— 客户端连接后会自动重新同步

命令中的容器名supersync-postgres、数据库用户supersync和库名supersync是默认配置；如果你的部署改过DB_CONTAINER/POSTGRES_USER/POSTGRES_DB，以你的docker-compose.yml为准。

为什么文档优先推荐这条路径：

• 避免部分恢复（partial restore）会引发的SYNC_IMPORT_EXISTS冲突；
• 客户端持有完整数据，它们才是权威来源；
• 产生的服务器状态干净、一致。

如何判断恢复成功：客户端重新连接后自动重新同步，所有设备收敛到一致状态。这条路径已被 e2e 测试验证，见 supersync-server-backup-revert.spec.ts 中的 "Accounts-only restore" 场景（多客户端收敛）。

路径二：整库恢复（兜底）

适用条件：所有客户端设备都丢失，没有任何客户端能重新上传数据。恢复出来的数据截止到所选 dump 的生成时刻，之后的变更丢失。

副作用说明（执行前确认）：下面的DROP SCHEMA public CASCADE会删除数据库中的全部schema 和数据，且恢复期间服务不可用（先 stop 后 start）。

# 1. 停掉服务器 docker compose stop supersync # 2. 删除现有数据，恢复全量 dump docker exec -i supersync-postgres psql -U supersync supersync \ -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;" gunzip -c backups/supersync_YYYYMMDD_HHMMSS.sql.gz | \ docker exec -i supersync-postgres psql -U supersync supersync # 3. 重新启动服务器 docker compose start supersync

库名（上例中的supersync）必须与你部署的POSTGRES_DB一致，先查你的.env或docker-compose.yml确认实际值。

已知限制：整库恢复后，如果客户端重新连接，服务器上已有的SYNC_IMPORT操作可能与客户端的 gap detection 机制冲突，报SYNC_IMPORT_EXISTS错误。文档给出的解决方式是：在应用里使用Reset Account功能清除该账号的服务端同步数据，然后重新同步。这是两条路径在"恢复之后"行为上的关键差别——仅账号恢复天然没有这个问题，整库恢复可能要为每个重连的账号手动走一次 Reset Account。

限制与相关说明

• 整库恢复不是免费的：它把服务器回退到备份时刻的状态。如果之后还有活着的客户端重新上传了更新的数据，会出现SYNC_IMPORT_EXISTS冲突，需要按上文 Reset Account 处理。
• 主机商的文件系统级备份不能替代 pg_dump：VPS 主机商提供的每日快照之类增量备份，对运行中的 PostgreSQL 未必是 crash-consistent 的；它适合用来兜住配置、TLS 证书、Docker 设置等 pg_dump 覆盖不到的服务器状态。pg_dump cron + 主机商备份组合才是文档描述的完整防护。
• 仅账号恢复与 E2E 加密账号兼容：恢复路径本身不触碰 op 负载，客户端（包括加密账号）重连后照常重新上传。

下一步

文档给出的延伸动作：把每日备份 cron 保持住（flock -n /run/supersync-backup.lock防重叠、3 天保留期的 crontab 配置见 backup-and-recovery.md），可选配置RCLONE_REMOTE把 dump 上传到异地（如 B2）。所有备份恢复场景（完全丢失、部分回退、仅账号恢复、混合加密/明文历史）的自动化验证都集中在 supersync-server-backup-revert.spec.ts，可作为你对自家恢复流程做回归核对的参照。

【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity