自托管 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 中都持有完整数据副本服务器只是中继客户端才是数据的权威来源。因此只要还有一台客户端设备活着数据就能恢复服务器端只独有账号信息邮箱、密码哈希和 passkeysWebAuthn 凭据这些无法从别处重建。数据存放位置为什么必须备份用户账号邮箱、密码哈希仅服务器没有它用户无法登录PasskeysWebAuthn 凭据仅服务器无法重新生成操作日志operation log服务器 所有客户端所有客户端设备都丢失时的最后手段任务/项目/标签数据由操作日志派生客户端可以从 ops 重建前提你已经配置了定期备份。备份由 backup.sh 生成两种 dump存放在脚本目录旁的backups/目录全量 dumpsupersync_*.sql.gz——完整数据库包含全部操作记录活跃实例约 300MB仅账号 dumpsupersync_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.logYYYYMMDD_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_dumpVPS 主机商提供的每日快照之类增量备份对运行中的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考