2026 数据库持续归档服务器租用手册：WAL-G 与 Litestream 的滞后窗口怎么定 + 恢复时间避坑全攻略

2026 数据库持续归档服务器租用手册：WAL-G 与 Litestream 的滞后窗口怎么定 + 恢复时间避坑全攻略

开篇：滞后窗口与恢复时间是两根反向的绳

给持续归档配服务器，最贵的一笔往往不是存全量备份的那块盘，而是「滞后窗口压到多小」——窗口每压小一半，上行带宽、对象存储请求次数和本地缓存盘的压力都要跟着变，而恢复时间又被保留期与快照间隔反向拽着。这句话拆开其实是四条彼此独立的账：日志往对象存储推得多快，决定了最坏能丢多少数据；全量或快照做得多勤，决定了恢复时要重放多久；保留期留多长，决定了每月那张对象存储账单的形状；本地缓存盘留多少余量，决定了前三条在凌晨出事时会不会先卡住。

WAL-G 与 Litestream 恰好是两个尺度上的样本。前者面向 PostgreSQL 的物理归档，是官方自述的 WAL-E 后续者，一个 Go 二进制通过环境变量或配置文件工作，把串行的 WAL 段变成对象存储里的对象序列，再用 backup-push 定期兜一层全量。后者贴着 SQLite 应用进程跑，不用改应用代码，默认每一秒同步一次 WAL 帧，同时周期性做完整快照。两者都不是装上就等于安全的工具，真正决定它们在生产里好不好用的，是那几个看上去不起眼的数字怎么配。

本篇只谈一件事：这套「流式归档 + 定期全量」的负载，服务器该怎么按「日志产生速率 × 滞后窗口 × 保留期 × 恢复时间」来配磁盘、带宽与 IO 余量。不涉及安装步骤，不做同类备份工具的横向评测，也不讨论主从切换怎么做。

两条链路的分工：WAL 流式归档压 RPO，定期全量压 RTO

先把链路的任务切开，不然后面的账会算混。连续层负责 RPO：PostgreSQL 侧是 archive_command 接 wal-g wal-push 把每个归档完成的段推上去，恢复侧用 wal-g wal-fetch 拉回来；SQLite 侧是 Litestream 这个独立进程持续读新产生的 WAL 帧并上传到配置的副本。离散层负责 RTO：PostgreSQL 侧是 backup-push 做的基础备份，SQLite 侧是 Litestream 周期性做的数据库文件完整快照。

恢复动作则是这两层的叠加——先取一份基础备份（或最近快照），再重放其后的日志。于是 RPO 近似等于连续层的滞后窗口，RTO 近似等于「拉回全量的时间 + 重放自该全量以来所有日志的时间」。这里藏着全篇最要紧的一条因果：压缩滞后窗口只能改善 RPO，并不会改善 RTO；改善 RTO 只能靠把全量间隔压短，而压短全量间隔又要多付存储和读 IO。两条目标在同一台机器上抢同一块资源。

在 WAL-G 里，链路上常用的命令有明确分工：backup-push 做基础备份，backup-fetch 取回基础备份，wal-push 与 wal-fetch 分别处理单个归档段的上传与拉取，backup-list 列目录，delete 管保留策略，wal-verify 做完整性时间线校验，另外还有为落后副本做追赶备份的 catchup。工具本身除 PostgreSQL 外也覆盖 MySQL/MariaDB、MS SQL Server，以及处于 beta 状态的 MongoDB 与 Redis。Litestream 的命令面就窄得多，它的复杂性不在命令，而在那几个默认值的真实含义。

WAL 产生速率怎么估：段大小、写入模式、archive_timeout 三个变量

估速率有三种口径，三种给出来的数不一样，配容量时要用对象存储那一侧的数，而不是数据库内部的写入量。第一种是段计数：统计归档目标里单位时间新增的对象个数与总字节，这是最贴近账单的口径。第二种是 LSN 差值：取两个时间点的 WAL 写入位置，差值除以秒数得到真实写入速率，这是最接近业务强度的口径。第三种是归档超时引入的下限：archive_timeout 会在段没写满时强制切换，切换即归档，于是归档体积里混进了大量只装了少量数据的「空心段」。

第一种和第二种之间的差额，主要来自 PostgreSQL 的已知机制：检查点之后的第一次修改会把整页写进 WAL（全页写），检查点越频繁、随机更新越密集，同一份业务数据对应的 WAL 体积越大。这部分没有通用倍数，只能按自己环境的抽样确定，但可以肯定它不是零。

三种写入画像对资源的要求差别很大。批量导入与批量更新的场景，日志段几乎都是写满的，单位有效数据对应的日志少，但瞬时速率高，冲击的是上行带宽的峰值。高频小事务配合密集随机更新、并且检查点开得很密的场景，日志膨胀明显，速率中等但持久，冲击的是日归档总量和对象存储容量。第三种是长静默加零星写入的场景，它最容易被忽略，因为它的账单由 archive_timeout 而不是由业务决定。

举个纯粹的算术例子：假设 PostgreSQL 的段大小为 16 MiB（PostgreSQL 从 11 起允许在初始化时指定段大小，默认值为 16 MiB，实际取值以所用版本的官方文档为准），archive_timeout 设为 60 秒。一个几乎空闲的实例，每分钟也会被强制切出一段来归档，也就是每天 1440 段，乘起来约 22.5 GiB/天，折算成持续归档速率约 0.27 MiB/s。窗口改成 30 秒就是约 45 GiB/天，改成 300 秒则降到约 4.5 GiB/天。这条曲线和业务写了多少数据完全无关，它纯粹是「窗口压到多小」这一项决定的，窗口一旦定窄，空闲实例也要为它付带宽、请求次数和容量三笔钱。

上行带宽账：峰值速率、压缩比取舍与限速参数的配合

上行需求的算式很简单：峰值原始日志速率乘以压缩后的留存比例。压缩这一层的取舍口径官方已经给得很清楚——LZ4 是默认选项，速度最快但压缩比最差；zstd 是折中方案，压缩比约为 LZ4 的 3 倍；LZMA 慢很多，压缩比约为 LZ4 的 6 倍；此外还有 Brotli，以及自 3.0.8 起提供的 none。官方给的是相对倍数而不是绝对值，所以绝对数字必须在自己的环境里抽样，不能跨环境搬。

把这组相对倍数换成带宽账，需要补一个假设。假设某业务的日志用 LZ4 能压到原始体积的 40%（这一条是假设输入，不是任何实测结果），峰值原始速率为 8 MiB/s，那么 LZ4 之后上行约 3.2 MiB/s，折合约 26.8 Mbps；换 zstd 约降到 1.07 MiB/s，折合约 9 Mbps；换 LZMA 约降到 0.53 MiB/s，折合约 4.5 Mbps。同一份日志，出网带宽需求差出五倍以上。反过来看，把压缩算法往慢的方向换，省的是带宽，付的是 CPU 与延时——如果那台机器原本就不是 CPU 富裕的型号，换 LZMA 之后瓶颈会从网卡挪到核上，端到端结果可能更差。

上行这条链上还有第二个计费维度：请求次数。段越小或者切换越频繁，单位时间的上传请求越多。沿用前面那个怠速例子，archive_timeout 为 60 秒时每天约 1440 次段上传，改成 30 秒就变成约 2880 次。请求单价与流量单价是两条独立的计费口径，具体费率需以对象存储厂商的实时资费页面为准，但结论不受费率影响——窗口压一半，请求次数翻一倍。

给业务让路这件事，要用限速参数而不是靠运气。WALG_DISK_RATE_LIMIT 限制的是 backup-push 期间的磁盘读取速率（字节/秒），WALG_NETWORK_RATE_LIMIT 限制的是上传速率（字节/秒）。全量备份窗口应当放在业务低峰，再用这两个参数把对业务的扰动压下去；但限得太狠会引出另一个问题：全量跑不完，下一次全量又到点了，堆栈里开始积压未完成的备份，最终演变成「有全量但不可用」。判断到底有没有卡住的办法，是看一次全量的实际耗时是否显著小于全量间隔。

加密环节也在上行之前完成，libsodium、OpenPGP、KMS 中的信封 PGP 密钥、AWS 与 Yandex Cloud 的客户端 KMS 都在支持列表里。它被忽略的原因通常是它不出故障：加密只在密钥没了的那天才出问题，那就是恢复当天。配归档链路时要把「密钥在哪里、谁能拿到、多久轮转」和备份一起纳入检查清单。

本地缓存盘账：wal-fetch 预取目录能吃掉多少空间

wal-fetch 会预取即将要重放的 WAL，把它们缓存在 ./.wal-g/prefetch 目录里，同时清理早于最近一次请求的缓存文件，避免无限膨胀。这条官方说明里有两个容易被忽略的字：相对。目录是相对于执行 wal-fetch 时的工作目录，不是某个固定绝对路径。挂载规划时如果不先搞清楚它落到哪儿，最容易的结果是：它被放到根分区或者容量最小的那块盘上，平时看不出问题，只有在真要恢复的那天把系统分区写满。

这块盘平时的压力可以忽略，恢复时却同时扛三份负载：网络下载的写、restore_command 的顺序读、以及数据库前滚自身的读写。它通常还有第四位客人——基础备份与增量包的解包写入。这四种是混合负载，顺序读本身对机械盘友好，但一旦有并发写入和随机读掺进来，寻道就会把吞吐吃掉；NVMe 之类的介质靠队列深度能把这几种压力摁在同一张大吞吐里。

容量怎么估，坦白说没有一个能写死的上限值。能给出的口径是：预取目录的峰值约等于「预取窗口内尚未播放的段数」乘以「单段大小」，前一个因子取决于当时前滚速度与网络速度的差、以及所用版本的实现方式，官方文档没有给出固定水位。工程上的做法是按若干 GiB 起步，把目录水位纳入监控，并且在每次恢复演练后记录实测峰值，用这个数去修正初始值——这也是演练的收益之一。

判断这块盘够不够的标准，是它是否慢于「下载带宽」与「前滚吞吐」两者中较慢的那一个。慢于下载带宽，缓存会空转、队列排起长龙；慢于前滚吞吐，前滚进程会时不时停下手来等 IO。两种情况最终都表现为同一个现象：估算里两个半小时的恢复实际跑了六个小时。这也是为什么给持续归档节点配存储时，不能只看容量大盘_utilization，而要看恢复路径上每一段的介质等级。

顺便说回写入侧：backup-push 要把整个数据目录读一遍，读吞吐不足会把全量窗口拖长。这时 WALG_DISK_RATE_LIMIT 反而是救场工具——它虽然名义上是限速，实际作用是让全量读取以一个可控的、不被 IO 争抢撕裂的速度跑完，而不是在和业务一起冲锋时被拖成龟速。

一张对照表：WAL-G 与 Litestream 在六个环节上的资源画像

下面这张表按链路环节列出两个工具的资源消耗类型、配错之后的表现，以及选型阶段要先确认的东西。它不是功能对比，每一行对应的都是某一份账单或某一次故障。

保留期与存储成本：retain、FIND_FULL、--permanent 与 delta 链的连带影响

delete 的语义里有一条最容易交学费的规则：它默认是 dry run，必须加 --confirm 才会真的删除对象。定时任务日志里写满「已删除」但容量纹丝不动的原因，九成在这里。确认参数之外的第二层是模式选择：retain 后接数字保留若干个备份，可选 FULL 或 FIND_FULL 修饰；before 后接备份名，删除该备份之前的所有备份，同样可带 FIND_FULL。

三者的区别在于对待增量的态度。直接写 retain 5，如果第 5 个备份恰好是 delta，操作会失败；写成 retain FULL 5，会保留 5 个全量以及它们各自带出来的 delta；写成 FIND_FULL，则会为第 5 个位置找到其依赖的那个全量并一并保留。想要永久留存的那一批，用 --permanent 标记，它会被保留策略自动排除。

这一切的前提是真正启用了 delta。WALG_DELTA_MAX_STEPS 决定两次全量之间最多允许存在几个 delta，默认值是 0，也就是默认不做增量、每次都是全量。决定是否成为 delta 的依据是文件系统的 ModTime 与数据文件中的页面 LSN，backup-fetch 会自动把 base 和它需要的那一串 delta 组合起来。官方文档还提醒过一句：基于 BASE_BACKUP 协议的远程备份不支持 delta。如果想把错误信息当成「为什么配了却没生效」的头号线索，这一条值得先读。

启用 delta 之后还有一次二选一：WALG_DELTA_ORIGIN 可以是 LATEST（默认，链式增量，后一个增量基于前一个增量）或 LATEST_FULL（所有增量都基于最近那次全量）。链式更省空间，但恢复时要按链条逐层取回组合，层数即延时；平行式每个增量体积更大，然而恢复只需要全量加最后一层。这正是开篇那句「反向的绳」在 PostgreSQL 侧的具体形态——同一次权衡，既出现在滞后窗口上，也出现在增量结构上。

容量算式可以写成一行，符号含义要自己填：某段时间的对象容量约等于「全量个数 × 单个全量体积 ×（1 + delta 相对占比）」加上「日均归档字节数 × 保留天数」。前一項由全量频次和保留窗口共同決定，后一項由归档窗口和业务写入量共同決定，两者的压缩比例还不一样。把每个符号的口径写清楚，比把结果算到小数点后两位有用得多。最后一笔是 WALG_S3_STORAGE_CLASS，默认 STANDARD，也支持 STANDARD_IA 与 REDUCED_REDUNDANCY；后两者能压低月度存储单价，但通常伴随取回另行计费与更低的可用性等级（具体以厂商实时资费为准）。被降级存放的那份数据，恰恰是出事那天最急着要读的那份。

SQLite 侧的镜像问题：sync-interval、快照保留期与 0.3/0.5 的静默差异

Litestream 是一条与 PostgreSQL 完全不同量级的链路，但记账逻辑一模一样。它把数据库置于 WAL 模式，持续读新的 WAL 帧上传到副本，同时周期性做数据库文件的完整快照；恢复就是下载最近快照再加上重放其后的 WAL 段，用 -timestamp 可以做时间点恢复。复制是单向仅追加的，目标端并不是一个可以写入 SQLite 端点，这一点在架构评审时经常被误读成「远端还有一个热备库」。

RPO 侧的默认值已经相当激进：sync-interval 默认是 1 秒，也就是说最坏情况下丢失大约 1 秒的写入，且这是异步复制。收到关闭信号时，Litestream 会先尝试把还没同步的 WAL 变更同步完再退出；至于同步复制，它在路线图上但尚未实现。对绝大多数 SQLite 场景，1 秒窗口的边际成本极低，真正该动手的是 RTO 侧的快照配置。

快照这一侧的默认值则相当保守。快照间隔默认不设置，规则是：只有当上一个快照因为保留期到期被移除时，才会生成新快照。默认保留期是 24 小时，于是在默认情况下大约每天一个快照，意味着最坏情况下要重放 24 小时的 WAL 段。写入频繁时 WAL 会不断累积，恢复时间随之线性变长。官方给出的建议很直接：缩短保留期，或者把快照间隔设为 1 小时。这又是一次用空间换 RTO——每天 24 份快照的存储占用，换来的是重放窗口从一天降到一小时。

高写入负载下还有一条隐蔽的坑。每秒数万个小事务的场景里，应用自己的 SQLite 实例可能会在 Litestream 的检查点之间自行执行检查点，导致某个 WAL 文件被 Litestream 漏掉；此时它会强制开启新的 generation 并做一次全量快照。官方的建议是设置 PRAGMA wal_autocheckpoint = 0。从服务器配额的角度看，这条建议的工程含义是：一次计划外的全量上传会在某个瞬间把上行带宽打满，如果那台机器的上行没有留余量，业务侧的对外服务会先感觉到。

同一侧的另一个参数是 PRAGMA synchronous。WAL 模式下可以设为 NORMAL，此时 fsync 只在 WAL 写满、需要把内容检查点回主库文件时才会调用；因为 WAL 本身是仅追加的，这样做是安全的。它换来的是写入延时的平滑，代价是崩溃时可能丢失最后一个检查点周期之后的已提交事务——这条边界必须和业务方讲清楚，因为它本质上在修改单机层面的持久性承诺。

再列几条会一次性毁掉副本的操作：多个应用向同一个 bucket 与 path 复制，会造成无法恢复的损坏；Litestream 不跟踪数据库的删除动作，重建库时必须同时删除 -wal、-shm 以及数据库旁边的 -litestream 目录。这两条的共性是——它们都不报错，只在你要恢复的那天才现形。

版本差异尤其要看。0.5 系列把 0.3 系列的 replicas 数组改成了单数的 replica 块；快照保留期 retention 在 0.5 中是根级 snapshot 块下的全局设置，如果照旧写在 replica 块内，会被静默忽略并回落到 24 小时的默认值；子命令方面，litestream wal 在 0.5 中改名为 litestream ltx。公开资料记录 v0.5.14 是 2026 年 10 月官方 Linux 安装页上所记录的版本，之后还有 v0.5.15（2026-07-21）与 v0.5.17（2026-08-31），版本演进与具体行为请以官方发布页为准。所谓静默忽略的实际后果是：你以为 6 小时保留期能换到每天 4 份快照，实际回落到 24 小时只剩 1 份，最坏重放窗口变成预期的 4 倍，而整套系统不会有任何一行报错。

恢复演练：三项时间怎么相加，完整性检查为什么不能跳

恢复时间由三段时间相加构成：把基础备份或快照拉回来的下载时间、叠加其上的日志重放时间、以及最后的校验时间。任何一项被低估，RTO 承诺就是空的。下载时间约等于全量体积除以取回带宽，而取回带宽受对象存储类别、是否跨地域、以及当时共享出口的拥挤程度共同影响。重放时间约等于自该全量以来累计的日志体积除以单实例前滚吞吐，这是唯一一项能被全量频次直接控制的变量。校验时间相对固定，但不能省。

还是用一组明确标注为假设的输入走一遍：基础备份体积 500 GiB，取回到主机的带宽假设稳定在 100 MiB/s，下载约需 85 分钟；日均归档量假设 169 GiB，需要重放最近 24 小时，假设单实例前滚吞吐 30 MiB/s，重放约需 96 分钟；校验另计。三项相加已经逼近三小时，而这组输入并不激进。现在把全量间隔从每周一次改成每天一次：下载时间不变，重放段从约 7 天降到约 1 天，按同一口径折算就是从十几个小时量级降到接近 100 分钟。全量的频次在平时只是一串 cron 配置，在这张表上却是恢复时间的大头。

WAL-G 侧给了几个把问题提前暴露的工具。backup-push --verify 会在备份阶段做页面校验和检查，让一部分坏页不用等到恢复时才被发现；wal-verify 做完整性时间线校验，用来回答「从这一份备份出发到底能不能一路追到现在」；需要低成本验证链路时，可以按库做部分恢复，只拉一个库出来，对落后副本还有 catchup 追赶备份。SQLite 侧的等价要求更朴素：官方和多篇公开教程都强调，必须先在临时目录做过一次真实恢复，跑完 PRAGMA integrity_check 再谈其他。

演练的纪律有三条。第一，目标必须是临时目录，绝不能覆盖生产数据目录，否则一次演练本身就会变成一次事故。第二，演练要记下两个数字：当时的实际耗时，以及当时的数据量。没有这两个数，下一次换算就还是拍脑袋，RTO 承诺书永远停留在纸上。第三，把它排进周期，而不是只在上线前做一次——对象、版本、业务量任何一个变了，上一次的结论就过期了。没有演练过的副本，无论它是对象的形式还是别的形式，本质上都只是一堆对象。

什么时候该把归档链路搬到单独的机器

共享机跑得好好的时候，独立一台机器只意味着多一份运维成本：多一台要打补丁、要监控、要做演练的机器。所以判断标准不该是「规模变大了没有」，而是下面这几条是否触发：

• 上行带宽被归档流量占满，业务对外服务已经受到影响，而用 WALG_NETWORK_RATE_LIMIT 限速到业务无感之后，RPO 已经不再达标。
• backup-push 期间的磁盘读与业务高峰严重争抢，限速到业务不受影响时，一次全量的实际耗时已经超过全量间隔。
• 预取目录与数据目录落在同一块盘，且这块盘已接近 IO 上限——典型征兆是真实恢复耗时明显偏离估算值。
• 一台机器上同时挂着多个库或多个实例的归档链路，单点故障的爆炸半径过大。
• 对象存储方向与业务出网方向不同，需要在路由和上行端口上做明确区分。

反过来说，单机单库、归档速率低、拓扑基本不动的场景，把归档留在原机完全合理。判断一句落地的话：先看共享机上跑出来的 RPO 与 RTO 是不是还在目标区间内，只有答案是否定的时候，才需要讨论新增一台机器。

决定部署位置之前，还有一条拓扑约束必须先读清楚。从副本执行 backup-push 时，WAL-G 会控制服务器的时间线；如果期间发生提升为主库或时间线切换，备份会被上传但不会被 finalize，WAL-G 会报错退出。换句话说，归档点挂在有可能被提升的实例上时，演练清单里必须包含这个场景，否则它只会在真正的切换那天出现。

这台独立的归档机如果真的要上，配置的重心也不在 CPU 数量上。真正要谈的是四件事：出网方向的带宽口径（峰值还是平均、独享还是共享）、给预取和临时恢复目录预留的独立介质盘、对象存储端的目录分级是否需要分离、以及扩容路径——当日志速率翻倍时，是先加带宽，还是先把压缩算法换成 zstd。这三件套想清楚了，机型选择反而只是一个执行动作。

WAL-G 与 Litestream 的滞后窗口，该按 RPO 还是按带宽定

答案应当是业务给的 RPO 在前，带宽在后。窗口是目标值，带宽是成本项，顺序一旦反过来，就变成「机房给我们多少上行，我们就忍多少丢数据」，这在任何一份容灾目标文档上都交代不过去。但反方向的追问同样要问出来：把 RPO 从 60 秒压到 1 秒，多出来的这一份上行费用、翻倍的请求次数和多占的本地缓存，业务是不是真的愿意买单。

落到两个工具上，落点其实不一样。SQLite 侧的 sync-interval 默认 1 秒已经是个很好的起点，因为单个 WAL 帧的体量很小，把窗口从 1 秒再往紧拧几乎不带来额外带宽压力，真正需要调的是控制 RTO 的快照间隔与保留期。PostgreSQL 侧的 archive_timeout 取 60 秒是常见的折中，但要记住它在低流量实例上是一条与业务量无关的地板——前面算的那 22.5 GiB/天就是这么来的。同样想把上行降下来，把压缩从 LZ4 换成 zstd 的杠杆明显更大，而且它不牺牲 RPO，只多花一点 CPU。

所以三个数要写在同一张表里：RPO 决定滞后窗口的上限（允不允许丢），带宽决定滞后窗口的下限（能不能长期付得起），RTO 决定另一端的全量与快照间隔。分开看任何一项都会配错——只看 RPO 会把带宽账单做成天文数字，只看带宽会把恢复时间拖到没人能接受，只看 RTO 则会发现全量频次自己就把 IO 和容量吃干净了。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。落到本篇这条归档链路上，我们会先和客户确认的不是 CPU 型号，而是这台机器往对象存储方向的出网带宽口径、月流量额度能不能覆盖峰值时段的那几个小时，以及给预取目录和临时恢复目录预留的介质是不是独立的一块盘——这些参数都属于需要实时询价才能确认的部分。

一万网络给持续归档节点的存储与带宽口径

把上面所有账合起来，交付前需要逐项确认的东西其实就下面几条，它们都不涉及具体报价，但每一条都会落到某一项资源配额上：

• 出网带宽的口径：是峰值还是均值、上行有没有承诺值、能否长期满负荷跑而不是短时突发。
• 月流量额度与超出后的处理方式，尤其是全量备份集中在低峰几个小时的形态能否被额度覆盖。
• 本地盘的分层：数据盘、预取与临时恢复盘、系统盘是否物理分离，避免出现预取目录悄悄写满根分区的情况。
• 机房到目标对象存储的链路稳定性，以及是否与桶同地域；跨地域带来的取回时延会直接进入恢复时间。
• 演练安排：能否提供一台同规格的临时机器用于定期恢复演练，演练产生的流量如何计入。
• 扩容路径：日志速率翻倍时，是先加上行带宽、先换压缩算法，还是先把全量频次降下来——这三种选择的成本结构完全不同。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。就持续归档这类节点而言，我们的做法是先把日志峰值速率、压缩后的上行需求、预取盘余量三项写成一张确认表，让业务方签字确认 RPO 与 RTO 目标之后，再按这张表去选带宽档位和磁盘组合；可提供的机型、带宽与流量组合以官网实时信息为准。