简要回答。
将应用与 PostgreSQL 放在同一个 Compose 网络上，仅发布 Web 入口，并将数据挂载到持久卷。在 VPS 之外尝试一次恢复，并测量一段负载期后再选择内存和存储。
- 应用可通过 Compose 私有网络访问数据库，无需将 SQL 端口发布到互联网。
- 卷在容器替换时保留数据。VPS 之外的副本可应对机器丢失。
- 在选择配置前，测量备份期间和流量高峰期间的资源消耗。
01分离三个服务
声明一个 HTTPS 代理、一个应用和一个名为 db 的 PostgreSQL 服务。将代理与应用连接到第一个网络，再将应用与 db 连接到第二个网络。这样代理就无法直接访问数据库。从应用容器内，SQL 连接指向 db 的 5432 端口。localhost 地址会指向应用容器自身。
02容器更换时保留数据库
固定 PostgreSQL 镜像的主版本。将命名卷挂载到该版本文档记载的数据位置。在预发布环境中创建一条测试记录，在保留卷的情况下重建容器，然后重新读取该记录。将凭据存储在仓库之外，并仅授予应用账户必要的权限。
03测试首次启动与重连
为 db 添加基于 pg_isready 的可用性检查。service_healthy 条件让 Compose 在启动应用前等待该结果。还要测试启动后的中断。PostgreSQL 恢复后，应用必须重新打开连接。随后通过 HTTPS 执行一次读取和一次写入，以验证完整流程。
04用你自己的测量结果选择规格
Wisp Spark 提供 2 vCPU、4 GB RAM 和 60 GB NVMe。Wisp Core 提供 3 vCPU、8 GB 和 120 GB。如果您的测试中整台机器达到 5 GB RAM，Spark 对这样的负载已经太小。至于磁盘，请把数据、索引、Docker 容器镜像、日志和恢复用的临时空间加在一起。
05在首笔客户订单前完成恢复
使用 pg_dump 以自定义格式导出数据库，然后在 VPS 之外保留一份加密副本。单独保留所需角色和用户上传的文件。使用 pg_restore 恢复到空的测试数据库。从应用中验证一条近期记录及其附件。为此操作计时，以了解你的恢复时间。
06判断单台机器是否足够
单台 VPS 简化了容器之间的通信。其不可用会同时停止数据库和网站。将测得的恢复时间与你的业务可接受的中断时间进行比较。如果该时长过长，请在开放服务前准备第二台机器和恢复策略。然后在预发布环境中测试切换。
来源与参考资料
如需深入了解技术要点并查找信息来源。