数据库备份（Neon 平台级）

用 Neon 平台自带的备份能力保护你的数据，应用代码完全不碰备份。这是最安全的方式：不写任何复制逻辑，也就没有复制出错、损坏数据的风险。

核心理念

备份是 Neon 平台的事，不是应用的事。

本项目的应用层（Next.js + Prisma）只负责读写数据库，它并不知道也不需要知道备份的存在。备份、恢复、时间点回滚全部由 Neon 平台承担，你只需要在 Neon 控制台点几下，或执行几条 SQL，即可获得：

⚠️ 为什么不让应用层备份？自动跨库复制生产数据是高风险操作，写错一条逻辑就可能损坏数据、覆盖主库。Neon 的备份是经过大规模验证的成熟能力，可靠得多。应用层唯一该做的，就是不主动删除/覆盖重要数据。

本项目支持多数据库（1 主库 + 最多 4 副库，见环境变量）。按"重要数据靠前、冷数据靠后"的原则，建议这样布局：

库	用途	放什么
主库 `DATABASE_URL`	核心数据	用户、工作区、文件、聊天、分享、外部连接、SSH 主机等一切重要/隐私数据
副库 `DATABASE_URL_2`	冷数据	审计日志、邮箱验证码（低优先级、可重建）
副库 `DATABASE_URL_3`	冷数据扩展（可选）	更多冷数据（当前版本仅审计/验证码可路由）
其余库	备份盘	不接入应用，仅作为 Neon 备份/恢复的目标

说明：应用目前只会把 audit（审计日志）和 verification（邮箱验证码）路由到副库（MULTI_DB_COLD_TABLES）。其余库如果不接入应用，就纯粹当作 Neon 的备份/冗余资源。你可以按需创建多个 Neon 项目或数据库，把重要的都放主库，其余做备份。

下面以 Neon 控制台操作为主。每一步都不需要改代码、不需要重新部署。

Neon 的每个项目默认都会保留数据历史（用于时间点恢复）。到 Neon 控制台 → 你的项目 → Settings，确认没有关闭保留。

如果希望有一个固定的、与主库解耦的备份副本，可以创建一个分支：

这个分支就是主库的一个完整副本，可以长期保留作为备份。它不占用主库读写，也不影响应用。

分支会在创建时保留主库当时的数据。之后主库继续写，分支不会自动跟随——这正是备份的意义：它定格在创建那一刻，是可靠的历史快照。

如果主库数据出了问题，两种恢复方式：

恢复是 Neon 平台的操作，应用只需在恢复后继续正常读写即可。如果换了一个新的连接串，只需在 Vercel 更新 DATABASE_URL 并重新部署。

如果需要离线备份或把数据导出到别处：

pg_dump "postgresql://...readonly..." > backup.sql

只读副本不影响主库，适合做定期冷备。

Q：应用层需要做备份吗？ 不需要。应用只读写数据库。备份、恢复全在 Neon 平台完成，应用代码无需任何改动。

Q：备份分支会占用数据库额度吗？ 分支是一个独立副本，会占用你的 Neon 存储额度（免费版额度有限）。建议保留 1~2 个关键备份分支即可，或用时间点恢复代替长期分支。

Q：我需要为每个副库单独备份吗？ 是的。如果副库（冷数据）也重要，请对每个库各自做 Neon 备份（在对应 Neon 项目/Branches 里创建分支）。主库和每个副库是独立的，备份也是独立的。

Q：数据库被误删 / 误改，能恢复吗？ 能。用 Neon 的时间点恢复（PITR）把数据库回滚到误操作之前的时间点即可。前提是 Neon 的数据保留期还没过（免费版默认保留一段时间，建议查看 Neon 控制台的保留设置）。

Q：备份会影响应用稳定性吗？ 不会。 Neon 备份、分支、只读副本都在平台侧进行，不占用主库读写，不经过应用代码。应用始终只连一个 DATABASE_URL，行为与平时完全一致。