Cloudways 暂存推送：怎样保留正式订单，而不是覆盖成旧数据库？

先选替换范围，而不只是点 Push

Cloudways 允许分别推送应用文件和数据库内容。Full DB 会替换正式数据库；Selected Tables 会覆盖所选正式数据表。两个选项都不承诺逐条合并新旧记录。

用一个说明性时间线理解风险：10:00复制暂存站，10:05客户下单，10:10再把旧数据库推回正式站。准备复制的快照里没有这笔新订单。收到部署成功通知，并不能证明订单仍然存在。

四项控制各有价值：只选文件可以避免不必要的数据库复制；指定数据表可以缩小替换范围；推送前可选备份提供恢复点；部署日志记录 Push/Pull 历史。但代码可能依赖数据库变更，指定表仍会被覆盖，备份不能阻止丢失，日志也不是业务数据审计。

选择数据表前，先核对 HPOS

WooCommerce 可以使用传统 posts/postmeta 存储，也可以使用高性能订单存储 HPOS。HPOS 把订单信息放入专门的数据表；当前配置决定哪些是主数据表、哪些是同步副本。兼容模式同步的是同一个网站内部的数据存储，并不是把暂存站与正式站自动合并。

因此，旧教程里“只排除 posts 与 postmeta”的办法，不能当作完整的现行订单保护方案。WP STAGING 的传统模式说明也把 HPOS 用户引向另外的指南，并提醒共享内容表还可能保存页面和布局。不能把其插件专用流程直接搬进 Cloudways。

应记录实际表前缀、主订单存储、兼容设置，以及扩展插件的依赖。商店不只有订单：客户资料、库存、退款、订阅状态和定时任务都需要发布安排。必要时让相应扩展开发者确认哪些数据必须保留，不要仅为方便部署就切换 HPOS。

先演练范围更小的发布

如果 CSS 或模板改动没有数据库依赖，先测试只发布文件。如果页面编辑器布局或设置保存在数据库中，应找出受支持的导入导出或可重复配置步骤，而不是整张复制混合用途数据表。WP Engine 自己的部署指南也区分文件、设置与破坏性数据库复制；但它的界面并不等于 Cloudways 的界面。

在受控副本中用虚拟交易演练准确的发布步骤，确认哪些内容会复制、哪些保持不变。支付回调、周期任务和其他集成都应单独安排；显示维护页面，并不能证明所有写入来源已经停止。

正式执行前，记录克隆时间，以及近期真实订单的标识、状态和库存值。确认最新备份已完成，指定恢复负责人并约定发布窗口。这些是编辑建议的验收方法，不代表 Toolnavia 已经执行上述操作。

同时验收旧记录和新业务

发布后，检查暂存复制前后的订单，再安全地完成一笔新的测试交易。对比订单标识、付款状态、商品明细、库存和客户权限，而不是只看行数或首页能否打开。外部支付和履约记录需要另行核对。

如果需要恢复，Cloudways Flexible 支持仅文件、仅数据库或完整恢复。恢复点采用 UTC 时间；官方建议至少预留应用数据大小2.5倍的可用空间。Rollback 只撤销前一次恢复涉及的范围，并不等于回退任意历史部署。

恢复旧数据库还可能再次删除较新的交易。选择操作前先保存相关故障证据。独立的[备份指南](/zh-cn/hosting/cloudways-flexible-backup-frequency-retention-restore-economics)说明保留期与可下载副本。

免费暂存不等于零成本商店

在现有 Flexible 服务器上建立暂存站，没有单独的暂存费用；另外启动服务器，则会产生正常服务器费用。两个副本仍然需要容量。价格页提供不同云厂商和服务器配置，不能把一个起步月价当作你的商店报价。应确认所选配置、持续收费、税费和附加项。

Flexible 异地备份另按每存储GB $0.033收费，再向上按$0.50档位取整，实际保存的备份数据决定这部分费用。开发时间与经过测试的发布流程也要单独预算；升级服务器不会把数据表覆盖变成交易合并。

什么情况下值得使用

团队能够验收数据流向时，可以为 Flexible 的分范围发布与恢复控制付费。迁移没有明确收益、现有环境已经可靠时，保留原方案也合理。无人能解释推送会替换哪些现有记录时，应先解决这个问题，再迁移。

联盟披露：通过本站 Cloudways 推广链接完成符合条件的购买，Toolnavia 可能获得佣金。