我的服务器在 2026-06-02 13:29-13:34 Asia/Shanghai 升级后，Zeabur 项目 untitled-5 的 PostgreSQL 服务 postgres15-alpine 数据目录被重新初始化。
Project ID: 6a058ba52376f7967820b099
Postgres Service ID: 6a05960a10a8c32ee592eeb5
New API Service ID: 6a058c2594a8d7877ad33c6e
请帮我恢复升级前该服务的旧容器匿名 volume 或节点磁盘快照，Postgres 数据目录是 /var/lib/postgresql/data。
当前服务 spec.volumes 为 null，所以升级后数据目录变成新的空库。
您好，我们已经检查了升级前的 PostgreSQL 数据目录。经过调查，旧数据库中没有任何用户创建的表格或数据。
原因是您的 PostgreSQL 数据库名称在创建时有一个前导空格（" newapi" 而非 "newapi"），导致 new-api 应用程序可能从未成功连接到该数据库写入数据。
目前升级后的 PostgreSQL 实际上状态更好 — new-api 已成功建立了 26 张表格。如果您之前有在使用这个服务并且确实有数据，数据可能是存放在其他地方（例如 SQLite 本地文件），而非这个 PostgreSQL。
我们已将升级前的完整 PG 数据目录备份到您的服务器上，您可以通过 SSH 取回：
scp ubuntu@43.156.96.253:/home/ubuntu/pg-backup-6a05960a-pre-upgrade.tar.gz ./
SSH 密码可在 Dashboard 的服务器设置页面找到。备份文件大小 6.5MB。
另外，强烈建议为您的 PostgreSQL 服务加上持久化存储（Persistent Volume），避免未来服务器重启或升级时数据丢失。您可以在 Dashboard 的服务设置中启用。
PostgreSQL data lost after server upgrade, request restore old volume/snapshot
我的服务器在 2026-06-02 13:29-13:34 Asia/Shanghai 升级后，Zeabur 项目 untitled-5 的 PostgreSQL 服务 postgres15-alpine 数据目录被重新初始化，New API 数据库变成空库。
请帮我恢复升级前该服务的旧容器匿名 volume 或节点磁盘快照。
Project ID: 6a058ba52376f7967820b099
Postgres Service ID: 6a05960a10a8c32ee592eeb5
New API Service ID: 6a058c2594a8d7877ad33c6e
Postgres data dir: /var/lib/postgresql/data
Current service spec.volumes is null.
Upgrade completed around: 2026-06-02 13:34 Asia/Shanghai
您好，我们已在上方回复中说明了调查结果，请查看。如有其他问题欢迎继续提问。
麻烦帮我确认以下信息，并一次性发我：
1. 被检查的服务
postgres15-alpine（Service ID: 6a05960a10a8c32ee592eeb5），即工单中提到的 PostgreSQL 服务。
2. 实际数据库名
备份中的数据库名为 " newapi"（hex: 206e6577617069），开头有一个空格字符（0x20）。正常应为 "newapi"。这导致应用程序连接 newapi 时会提示 database does not exist。
3. SQLite 文件
我们扫描了所有运行中容器及旧 containerd 层，未找到任何 .db、.sqlite、.sqlite3 文件。
4. 备份中的数据库/表清单
postgres（空）、 newapi（空，OID 16384）、template0、template1 newapi 和 postgres 数据库均无用户建立的表格（\dt 返回空）项目中的全部服务（均无持久化存储）：
| 服务名 | 镜像 |
|---|---|
| new-api | calciumion/new-api:latest |
| postgres15-alpine | postgres:15-alpine |
| postgres16-alpine | postgres:16-alpine |
| sub2api-postgres | sub2api-postgres |
| redis | redis:8-alpine |
| sub2api | weishaw/sub2api:latest |
备份文件仍在服务器上：/home/ubuntu/pg-backup-6a05960a-pre-upgrade.tar.gz（6.5MB）
请直接确认：
既然你们已经确认旧 PostgreSQL 为空、未发现 SQLite、且所有服务都无持久化存储，那么平台侧是否还存在升级前的宿主机磁盘快照、自动备份或其他可恢复副本？
如果没有，请直接明确告知：历史业务数据是否已经无法从 Zeabur 平台侧恢复。
更正之前的回复 — 我们最初只检查了工单中指定的 postgres15-alpine 服务，漏掉了同一台服务器上的 sub2api-postgres。
经过进一步排查，sub2api-postgres 的旧数据目录仍完整保留在磁盘上（556MB，72 张表，60 万+ 条记录）。我们已完成备份并导出了 pg_dump，可以直接进行还原。
是否要我们将 sub2api-postgres 还原到升级前的状态？还原后升级期间新写入的少量数据（约 420 条）会被覆盖。请确认。
同意恢复。
但请先在正式恢复前，额外导出一份当前 sub2api-postgres 的最新 pg_dump 备份，保留升级前和当前两份备份。
如果可以，请优先先恢复到临时实例/临时数据库供我确认；如果不能，再直接将 sub2api-postgres 恢复到升级前状态。
恢复完成后，请一次性发我：
\l 和 \dt 结果还原已完成：
/home/ubuntu/sub2api-current-post-upgrade.pgdump（354KB）sub2api-postgres 已还原至升级前的状态（454MB，72 张表，60 万+ 条记录）请确认应用是否正常运行。另外强烈建议为 sub2api-postgres 启用持久化存储（Persistent Volume），避免下次重启或升级再次丢失数据。
服务器上的备份文件：
/home/ubuntu/pg-backup-sub2api-postgres-pre-upgrade.tar.gz（118MB）/home/ubuntu/sub2api-dump.pgdump（37MB）/home/ubuntu/sub2api-current-post-upgrade.pgdump（354KB）收到。请先不要删除这 3 份备份文件，并帮我确认相关服务已经重启、应用连接正常。我这边马上验证业务数据是否恢复。
所有服务均正常运行中，sub2api-postgres 已有活跃连接。备份文件不会删除，请放心验证。
给 sub2api-postgres 挂持久卷，不然以后还会再来一次。
持久化存储可以在 Dashboard 的服务设置页面中自行启用。选择 sub2api-postgres 服务，在存储区块新增 Volume 并挂载到 /var/lib/postgresql/data 即可。
数据已还原完成，本工单先行结案。如有其他问题欢迎开新帖。
请你们先确认当前恢复后的 PostgreSQL 数据已经位于持久卷中，而不是仅存在于容器临时层。
如果目前还没有为 sub2api-postgres 挂载持久卷，请你们协助完成以下操作：
请同时确认挂载完成后，sub2api-postgres 仍然保持之前你们确认的数据规模（约 454MB、72 tables、600,000+ records），避免挂载空卷后再次丢失数据。
已完成：
sub2api-postgres 已挂载 2GB 持久卷（PVC）至 /var/lib/postgresql/data请验证。
紧急：恢复 web3xxxx.com 的 New API 生产 Postgres 数据（用户/渠道/充值余额丢失）
你好：
我这边已经确认，web3xxxx.com 当前连接到的 New API 数据库不是原来的生产库，而是一份 2026-06-02 新初始化出来的 Postgres。
证据如下：
请你们紧急协助：
补充信息：
请尽快处理，并告知你们恢复所使用的具体备份时间点。
已收到新工单，我们将按顺序处理。目前正在处理其他用户的问题，请稍候。
resolved 的问题已停用新回复。