已审阅 · Hosmio 资源
开始之前
选择一次性目的地和书面测试范围。确认对应用程序代码、所需软件版本和批准的备份材料的访问权限。将目标与生产环境分开，在有意测试之前禁用出站通知、计划任务和外部写入。
01
列出必须迁移和必须重建的内容。
包括运行时、数据库、上传文件、配置、计划任务、证书、DNS 所有权和外部集成。记录谁控制每个依赖项，以及如果当前 VPS 不可用如何恢复访问。识别任何需要替换而非文件复制的供应商特定功能。
写下预期的版本和扩展。一条获取今日最新版本的安装命令可能无法重建您所运行的应用程序。引用受保护的密钥存储来管理凭据；恢复计划应说明授权人员如何在不将密钥放入计划本身的情况下取回它们。
02
选择数据感知的导出和恢复方法。
对于 PostgreSQL，使用 pg_dump 进行逻辑导出覆盖单个数据库，而角色等全局对象需要单独处理。该工具拒绝从高于客户端支持的主版本号的服务器进行转储。官方文档也提醒不要将 pg_dump 视为通用的常规生产备份策略。 PostgreSQL：pg_dump ↗
与您的操作人员一起，根据应用程序和恢复需求选择合适的方法。记录导出所省略的内容，以及文件如何与数据库引用保持一致。命令成功返回是有用的初步检查，但并不能证明完整的应用程序已被保留。
03
恢复到明确独立的目标。
在恢复之前检查归档文件和目标位置。PostgreSQL 归档恢复使用 pg_restore；清理现有对象的选项可能删除数据，其默认行为可能在 SQL 错误后继续执行。规划错误处理并检查结果，而不是假设每个对象都已恢复。 PostgreSQL：pg_restore ↗ 不要仅仅因为名称熟悉就对生产数据库运行教程。
对于文件备份，选择预期的快照和一个空的测试目标位置。Restic 文档说明恢复可能覆盖现有文件；中断的覆盖可能留下不完整的结果。 restic：从备份恢复 ↗ 在演练记录中记录源快照和目标路径。这些是方法选择指南，不是针对 Hosmio VPS 执行或验证的命令。
04
检查用户任务和隐藏的副作用。
| 检查 | 需保留的证据 | 结果 |
|---|---|---|
| 应用程序以文档记录的版本启动 | 版本清单与启动结果 | 尚未测试 |
| 代表性记录和文件一致 | 合成记录与附件检查 | 尚未测试 |
| 权限行为正确 | 两个测试角色与预期访问权限 | 尚未测试 |
| 作业不发送重复的外部工作 | 出站操作已禁用或受控测试 | 尚未测试 |
| 替代操作员能遵循记录 | 独立走查与缺口 | 尚未测试 |
尽可能使用合成账户和无害的测试记录。除了验证读取成功外，还要验证访问边界。一个能启动但授予错误权限的应用程序不是成功的恢复。将有失败的检查连同整改负责人一起保留在记录中。
05
规划新写入改变决策的时间点。
演练应为未来迁移的顺序提供参考：最终一致性步骤、目标检查、流量切换、验收决策和旧服务退役。确定谁可以停止或撤销操作。如果目标位置已接受新写入，将用户送回旧副本可能会丢失或分裂这些写入；回滚需要数据方案，而不仅仅是 DNS 更改。
在预算中考虑重叠。可能需要第二台服务器、独立存储、流量费用、许可证和操作人员时间。不要假设供应商会按比例退还 VPS 费用，也不要假设预付款可退还。Hosmio 公布的周期价格描述的是预付条款；它们不定义迁移或退款服务。
06
留下另一位操作员可以使用的证据。
仅在演练实际执行后，记录演练日期、版本、副本标识符、目标、耗时和结果。在此之前使用“已计划”或“未测试”。将验收表与恢复记录一起保存，并列出仍阻碍独立重建的依赖项。
如果演练失败，对缺口进行分类：数据缺失、软件不兼容、凭证不可用、外部依赖或流程不明确。解决最小的阻塞问题，然后重复受影响的检查。在关键任务仍未测试时，不要声称应用程序可移植。
将计划连接到 指定的运营职责 和 客户方的变更审批流程。预期结果是在文档记录的范围内展示恢复能力，而不是承诺零中断或自动交付迁移。