MikuCloud数据库恢复要买更多核心吗？逻辑归档与完整恢复窗口怎样验收

备份文件已经下载到新服务器，恢复却超过了约定停机时间，这时临时购买更多核心未必来得及，也未必有效。把MikuCloud列入自管数据库主机候选时，应先拿一份真实业务备份，确认它允许怎样恢复、最慢环节在哪里，以及恢复完毕后应用还要多久才能接单。本文只讨论逻辑备份恢复的采购验收，不将渠道商家的网络介绍当作数据库性能证据；没有在MikuCloud进行实测，也不承诺任何一档资源能在固定时间内恢复。

先把“恢复完成”写成业务能签字的时刻

文件全部导入和业务恢复营业之间，通常还隔着索引、约束、权限、扩展与应用检查。采购时如果只报数据库文件大小，商家无法据此判断恢复工时，自己也很难比较两台服务器。更有用的交付物是一条完整时间线：目标环境准备好，备份可读取，数据加载结束，必要对象建立成功，应用抽查通过，最后才是允许写入。每个时刻都需要独立记下，而不能把命令结束当成唯一成绩。

PostgreSQL的pg_restore可以把数据加载、索引创建和约束创建等耗时操作交给多个并发会话，但文档明确指出，最佳并行度取决于服务端、客户端及网络的硬件条件。因而“四个作业”只是同时工作的上限，不是四倍吞吐的合同。如果原始业务主要集中在一个大表，或后半程只有一个重要对象仍在处理，总时间不会随作业数等比例缩短。这个判断属于恢复计划的边界，不能被更高的核心数自动消除。

在验收记录里，把恢复期间的磁盘读写、CPU占用、可用内存、错误日志和各阶段耗时放到同一个时间轴。只有观察到某段持续受CPU限制，且新增并行工作确实缩短该段时间，才有证据为更多算力付费。若提高并行度后磁盘等待上升、应用检查更慢，应优先降低并发或分离恢复存储，不能只追求导入阶段的瞬时数字。

手里是什么格式，决定了能够买到什么加速

恢复方案要在生成备份时就决定一部分。官方文档说明，custom与directory归档允许选择、重排归档项目，并支持并行恢复；directory是支持并行导出的格式。这意味着把普通SQL文本文件复制到一台更多核心的机器，并不能直接按同样方式使用pg_restore的并行归档恢复功能。不要等到迁移当天才发现，现有产物与计划使用的工具不相配。

另一条经常影响部署的条件是输入位置。pg_restore的并行模式只支持custom和directory归档，输入必须是普通文件或目录，不能是管道或标准输入。 如果原计划从远端边下载边流式恢复，改为并行恢复就需要重新设计本地暂存和校验。此时新增磁盘并非“让数据库更快”，而是为备份落地、失败保留和重新读取提供条件。这笔空间必须与目标数据库、恢复过程临时空间分别列账。

备份一致性也应独立核对。pg_dump会在数据库仍被并发使用时取得一致的导出，但它一次只导出单个数据库；角色、表空间等跨库全局对象需另行处理。因此一份归档可读，不能证明新环境的登录角色、授权和扩展条件已经齐全。将这些前置条件漏给供应商，会让一场看似存储不足的采购讨论，最后变成迁移当天补权限和补环境的加班。

一份六小时窗口的预算，先算最慢的可控环节

以下全部是用于询价的方法算例，不是MikuCloud配置、报价或测试结果。假设离线归档有120GiB，备份读取到目标暂存盘的有效速度稳定为40MiB/s，纯传输下限就是120乘1024再除以40，得到3072秒，约51.2分钟。这个结果尚未包括重试、校验、连接建立与争用。若商家只给端口速率，不能直接拿来代替这里的有效文件传输速度。

再假设目标窗口是六小时，并且演练把环境准备与完整校验合计预留四十分钟，把应用抽查和切换预留五十分钟；当前方案采用先下载再恢复的串行安排。扣掉51.2分钟传输后，归档恢复本身最多还有218.8分钟。在这组假设下，恢复段超过218.8分钟，整套方案就无法按六小时交付。增配是否值得，应该看它能否把恢复段压进这个剩余预算，而非看套餐宣传中的主频与核心数。

空间同样要按恢复峰值估算。另设解压和重建后的目标数据及索引合计260GiB，本地归档仍保留120GiB，操作系统、日志及明确预留的其他空间合计40GiB，那么在不计恢复额外临时文件之前就需420GiB。若磁盘可用容量只有400GiB，哪怕原业务所占空间远小于400GiB，这个恢复安排也已经不成立。这里用的是GiB，不可把商家标注的GB不经换算直接填入；临时文件和增长余量仍需从演练取得，不能随手加一个固定百分比便声称安全。

费用比较应包含一次性恢复实例、旧实例交叠、备份存储、传出流量以及失败后重做的工时。更大的常驻实例未必是最低总成本：如果平时业务规模较小，而恢复极少发生，可以比较临时恢复到较大实例后再迁移的方案。不过这种方案多了一次数据交接与验收，若商家不支持合适的迁移或短周期付费，就可能比直接购买常驻余量更麻烦。所有费用都应以订单和结算条款为准，本轮没有取得MikuCloud现价，故不填写虚构的价格对照表。

要并行，还是要整次失败回滚，提前选清楚

pg_restore的多个作业不能与single-transaction选项合用；单事务选项的用途是让全部命令成功完成，或者整次不留下修改。这会影响恢复失败后的处置方式。如果追求并行导入，同时又默认为任何错误都自动回到空库状态，验收预期就相互冲突了。应在演练前确定：失败时保留现场定位，还是销毁目标库重建；哪些错误必须中止；重做需要重新下载归档还是可以复用已经校验的本地文件。

操作时应使用隔离的新目标环境，保留命令、工具版本、开始与结束时间以及错误输出。文档提醒，恢复归档可能执行源端超级用户选择的任意代码；不可信来源的备份应先检查内容，不能直接对生产目标执行。这也是为什么一条网上复制的恢复命令，不能代替本地可审阅的作业。涉及清理或重建数据库的选项，更应在隔离环境验证含义，不让恢复演练本身破坏仍可用的业务。

数据加载完后，应检查必要角色与授权、扩展版本、关键表数量及业务约束，再执行具体应用查询。优化器统计若未完整恢复，可按官方说明对恢复的表运行ANALYZE；不能把刚恢复后第一次慢查询立刻归因为新主机性能差。业务抽查还要覆盖写入及异常处理，而不是只检查能连上数据库。能否在失败后重新开始、归档是否仍可使用、复核记录能否复现，都应成为交付的一部分。

MikuCloud候选订单只接受能回答这些问题的条件

本轮推广资料来自2026年10月30日核验保存的渠道通网站17广告快照，对应商家记录为mikucloud；渠道通与商家官网本轮请求均超时，推广跳转也未能完成实时连通性核验。快照能够证明当时收录了该商家及推广链接，不能证明当前可售产品、数据库托管能力、价格、库存、退款条件或线路表现。这里的技术分析用于自管数据库主机询价；若实际销售的产品不提供所需操作系统与存储控制，就应排除该订单。

在决定询价时，可通过MikuCloud推广入口：查看当前可售服务并核对订单条件联系商家。该链接具有推广关系，当前连通性尚未确认。不要仅凭渠道快照付款，应让商家把所售产品与本次恢复需求一一对应，尤其不能把普通网络服务介绍理解为代运维承诺。

询价单要直接问：磁盘标称单位与实际可用空间各是多少，恢复期间是否存在持续写入或共享资源限制，能否创建隔离目标库并自行安装所需版本，归档下载产生哪些流量费用，短期测试与退款条款是否允许完成整次演练。还应确认扩容是否停机、旧盘是否保留、失败重建是否收费、供应商负责到操作系统还是数据库层。对方没有答复的项目，就按“未承诺”处理，不能在预算中当成已经包含。

适配的场景是愿意自行管理数据库、能在付款前明确产品能力，并有时间拿真实归档做完整演练的团队。要求固定恢复时限却没有样本、只保存单个逻辑归档却要求任意时间点恢复，或希望商家自动补全角色与扩展的项目，都不应直接按本方案下单。逻辑恢复的验收记录最终要给出三个可执行结果：归档格式与输入位置可行，峰值空间足够，业务签字时刻落在剩余窗口内；有一个结果缺失，就先补演练或改恢复设计，再谈购买更多资源。

资料与计算口径

PostgreSQL逻辑备份格式与一致性

PostgreSQL归档恢复与并行条件