升级与备份你的部署
数据卷保留不等于备份，备份文件存在也不等于已经证明可恢复。请先在隔离环境恢复并核对业务数据，再删除旧部署。以下区分数据位置、停写备份、恢复验收和跨版本升级；不要把容器重启测试当作 EBS 恢复或实例重启的证据。
数据和配置在哪里
下文的数据卷、挂载、快照与恢复步骤适用于有持久化数据卷的部署，包括未声明持久化模式的旧记录。只有明确声明 deploy.persistence: none 才表示无应用数据盘，不能根据应用名称或分类猜测。此模式应通过浏览器下载或导出成果、保留本地备份，并在升级或删栈前验证保存的文件。服务器不持久化应用数据，浏览器存储不等于备份；没有需要恢复或在删栈后保留的应用数据盘，主机配置及代理凭据仍位于系统盘。实例和系统盘仍会计费，请核对费用与资源清理。
| 内容 | 位置及备份边界 |
|---|---|
| 应用持久数据 | 主机 /var/lib/corenova/app/data 挂载到应用声明的容器目录，位于加密 EBS 数据卷。 |
| Ghost | 容器内 /var/lib/ghost/content，默认包含 SQLite 数据库、上传图片等内容；仅导出文章不能替代完整目录备份。 |
| Uptime Kuma | 容器内 /app/data，默认 SQLite 及应用配置；恢复后须核对监控、账号和通知设置。 |
| n8n | 容器内 /home/node/.n8n，包含默认数据库及本地配置；凭据解密需要原加密密钥，仅导出工作流不够。外部注入的密钥需另外安全备份。 |
| 主机配置及代理凭据 | /opt/corenova/env、/opt/corenova/credentials/admin.txt、Nginx 配置和 TLS 证书位于系统盘，不属于数据卷快照。新栈需要重新配置，不能把旧代理密码当作应用管理员密码。 |
| 外部数据库、文件和服务 | 不在本栈数据卷中，必须按对应服务的方式单独备份。 |
模板启动应用前应确认数据卷已经挂载；缺盘、未知文件系统或挂载失败必须阻止启动，不能回退到系统盘目录。旧部署不会因本站代码更新而自动获得这一保护。
停止实例通常保留两块磁盘；删栈默认删除系统盘，但保留数据卷并继续计费。删除保留卷将永久丢失卷中数据。清理前请阅读费用与资源清理，按实例 Storage 中记录的卷 ID 核对，不能仅凭名称判断。
最小备份路径：停写后备份整份数据
以下操作需要你在自己的 AWS 账号执行，会产生快照及可能的额外资源费用。它是人工操作路径，不表示当前版本已经完成你账号内的 EBS 恢复演练。
- 在正确区域记录栈名、
InstanceId、数据卷 ID、应用版本、镜像完整tag@digest、数据目录和必需的环境配置。敏感配置放在受控的秘密存储中，不要写进工单或公开日志。 - 安排维护窗口，暂停外部写入。通过 SSM 停止应用服务，例如 Ghost 使用
sudo systemctl stop corenova-ghost；Uptime Kuma 和 n8n 分别使用corenova-uptime-kuma、corenova-n8n。确认容器已停止，不要只关闭浏览器。 - 在 EC2 → Volumes 选择记录的数据卷 ID，创建快照并记录快照 ID。确认快照状态为
completed后再恢复写入；如果快照失败，不要删除原卷。 - 通过 SSM 启动同一服务，检查登录和一条业务数据。保存备份日期、镜像 digest、快照 ID 和恢复演练结果。
- 根据应用需要额外执行原生导出。Ghost 内容导出不含全部图片、主机配置和凭据；n8n 工作流导出不等于可解密的凭据备份。
AWS Backup 可以安排自动快照，但计划必须实际关联到目标卷，且要监控作业成功、保留期、告警及恢复演练。快照不会自动处理应用停写，也不能承诺“配置一次后不用再管”。
最小恢复路径与验收
不要直接覆盖原卷，不要只把快照卷挂到 /dev/sdf 就启动应用。 Linux 设备名、文件系统 UUID、挂载点、权限和 CloudFormation 资源关系都需要核对。
- 保留原栈与原卷，创建同一应用版本和镜像 digest 的隔离新栈；保持私有访问，避免恢复的监控、邮件或工作流对外触发。
- 停止新栈的应用服务。从快照在新实例所在可用区创建恢复卷，记录卷 ID。由具备 EBS/Linux 挂载经验的操作人员附加并识别恢复卷，检查文件系统与权限，不能猜测 NVMe 设备序号。
- 将恢复卷只读挂载到独立临时目录，确认其中有预期数据库、上传文件及配置。将数据完整复制到新栈已挂载的数据卷，保留所有者、权限和隐藏文件；不要格式化恢复卷，也不要把复制目标设为未挂载的空目录。新栈数据应为空且可丢弃，非空时先另外备份。
- 安全恢复必要的应用密钥和配置；核对镜像用户、数据目录和实际挂载关系。不要直接覆盖新栈的主机配置、代理密码或证书。
- 启动应用，在私有通道中完成下面的业务验收，再重启应用并重复检查。确认不会触发真实外部通知后，才逐步恢复访问与任务调度。
- 验收失败时停止新环境，保留原栈和备份排查；不要让两个实例同时写同一数据库或用未确认的副本覆盖原数据。
| 应用 | 恢复后必须核对 |
|---|---|
| Ghost | 原账号能登录，指定文章标题及内容正确，上传图片可读取，还能发布新文章。 |
| Uptime Kuma | 原账号、监控项和通知配置存在，隔离测试目标的故障与恢复能被检测，本地测试接收端实际收到通知。 |
| n8n | 原账号和工作流存在，凭据可正常解密；隔离工作流可以再次执行并得到正确结果。 |
这条人工 EBS 路径尚不能替代真实云端恢复验收；跨版本迁移、灾备切换、自动回滚和高可用不在本轮保证范围内。若不熟悉磁盘识别和挂载操作，请在删除原数据前寻求有经验的运维协助。
升级到新版本
- 先完成旧版本备份与同版本恢复演练，并阅读上游迁移说明。
- 从版本历史选择目标版本，查看部署准备和费用，再创建独立新栈。
- 保持新环境私有，按上游要求迁移数据；不要假定新旧数据库格式兼容。
- 验证登录、业务数据、写入、外部地址及回调，再安排停写和切换；切换期间要防止新数据分叉。
- 保留旧环境直至验收结束。确认不再需要后删除旧栈，并分别处理保留卷、快照和日志；删旧栈不代表所有费用停止。
失败升级同样产生资源费用。新旧两套环境并行期间都需要预算；实例终止保护可以减少误操作，但不能替代备份和恢复验收。