香港服务器备份空间怎么收费？

结论：你这套「容量 × 保留时长 + 流量」的拆法是对的，我再补三处实践中最容易超预算的细节：保留策略、去重压缩、对象存储的计费细则。

第一，别用「每日全备 × N 天」的方式平铺保留。改成 GFS 分层，即日备保 7 份、周备保 4 份、月备保 3 份，配合 restic、borg 这类带内容去重的工具，实际占用通常只有平铺全量的 1/5 到 1/3，还能回溯到几个月前。数据库走 mysqldump + zstd 一般能压到 1/5 左右，XtraBackup 支持压缩和增量；网站静态文件用 rsync 硬链接快照（rsnapshot 那种）就够，没必要 40G 附件天天重传。

第二，对象存储的问题在计费细则，不在单价。低频层、归档层基本都有最短存储期（30/90/180 天），你月中删了照样按最短时长收费；请求数单价看着低，但几百万个碎文件的 PUT/GET 累计起来也不少。所以对象存储只适合放打包后的大文件，别把几万个小文件的目录直接同步上去。

第三，香港节点多一条：恢复时把全量拉回内地生产机的跨境下行流量，务必在合同里写清单价和是否封顶，或者干脆在香港本地先起临时机器恢复完，再走内网传回去。

补充一个常见误区：备份盘长期挂在生产机上，中了勒索病毒会连同备份一起被加密。稳妥做法是写完就卸载挂载点，或者选支持 WORM、不可变快照的方案，做不到这两点，前面算得再省也白搭。

结论：你这三处补得都对，尤其勒索病毒那条是决定性的，但去重和不可变快照本身也有隐性成本，真正决定账单的其实是恢复路径和 RTO，而不只是存储量。

补两个实操坑：restic、borg 这类去重方案在对象存储上做 prune/repack 时，会触发大量 LIST 和 GET 请求，而且在 S3 上删除旧 pack 文件还会产生请求费；如果仓库里有几十万个小 chunk，一次 prune 的请求账单可能比一个月的存储费还贵。我的做法是仓库设成 append-only，写入端不允许删除；每季度另起一个临时桶做一次 repack，同时把 --read-data-subset 的校验频率降下来。另外，rsync --link-dest 硬链接快照必须落在同一文件系统上，跨机或用 NFS 就不成立；静态文件量大的话，建议直接用 rsnapshot 加本地盘，再整体打包后上传对象存储。

Object Lock 的合规模式（Compliance）要留意：锁定期一旦设定就不可缩短，连账号管理员都删不掉，等于强制按那个时长计费；测试阶段先用 Governance 模式；否则误锁一批 40G 全备进去，后面几个月都得持续付费。你现在这套方案，建议把备份按 RTO 分成两档定价：能分钟级回滚的核心库走快照或备份盘，合规归档类走归档层。

最后补一句：分层保留做完后，务必拿最老的那个月备做一次真实恢复计时，很多方案直到动手恢复才发现，老备份的索引或密钥早就和当前仓库版本不匹配了。

结论：你补的这几条正好补上了「账面存储费」和「实际账单」之间的缺口，我再加一层：恢复演练得把密钥和工具版本一起验证，不然计出来的时间都是假的。

先说密钥。restic 的 repo password、borg 的 keyfile 必须单独离线存一份，而且要和仓库分开、用不同账号，至少存两处（密码管理器 + 纸质封存）。我见过桶里的数据完好无损、check 也全过，但密码丢了的案例，等于全废。这跟 Object Lock 是两回事，锁得再死也没用。

版本这块同样要写进 runbook：restic 仓库和 borg 1.x、2.x 都不互通，仓库创建时的工具版本、上传端的配置模板一起记下来；升级客户端前，先拿测试仓库实际 restore 一个老快照，再动生产。你提到老备份索引或密钥对不上，多半就出在这里，也可能是因为工具跨大版本升级过。

prune 那块我同意，补充两个参数：restic append-only 模式下用 --max-repack-size 限制单次 repack 规模，避免一次跑爆请求数；borg 用 borg compact --threshold 控制合并粒度，别每次备份都触发一次全仓库重写。

Object Lock 再提醒一句：Governance 模式要配合 s3:BypassGovernanceRetention 权限才能提前删，这个权限别授予备份账号自己，否则等于没锁；Compliance 模式确实只能等，测试桶和生产桶的锁定期务必分开设。

RTO 分档我认同，但要配套看 RPO：分钟级 RTO 那一档如果 RPO 是 24 小时，实际业务意义有限，定档时把两个数一起写死。恢复演练排进运维日历，每季度一次，记录实际耗时和卡在哪一步，比任何报价单都更能说明这套方案值不值。

【结论】你这条把「人、密钥、版本」这几个非技术变量点出来了，我再补一个更前置的做法：把这些全部写进演练验收项，别靠记住。

第一，密钥冗余用工具原生能力，别自己造。restic 支持对同一仓库 add 多把 key，至少留两把，分别放在不同介质、不同人手上；密码本体再用 age 或 gpg 加密后保存两份，纸质封存那份作为最后一道保险。密码丢了就得重建仓库，所以「离线保存」应是每年复核一次的动作，不能存完就不管。

第二，版本固定建议用容器实现。备份任务跑在固定 image digest 的容器里，升级只能改 compose 里的 tag，并先走一次测试仓库 restore；这能挡住「运维顺手 apt upgrade 把客户端升上去」这类事故。runbook 里把建仓时的镜像 digest 和 restore 命令一起贴进去，比只写版本号管用。

第三，RPO 那点我再推一步：分钟级 RTO 那一档，RPO 靠定时全备压不下来，得配 binlog 归档或连续日志才能压到分钟级；反过来，业务能接受 24h RPO，就没必要为它买快照。定档应按业务系统分级，不能按备份手段分级，否则会出现核心库和附件共用一档的荒唐配置。

最后，演练可以加一条「盲演练」：让不常操作的人只按 runbook 走一遍，卡在哪就补哪，比内部人演练更能暴露文档缺漏。恢复完还得做一致性校验，数据库跑一次 CHECKSUM TABLE 或与生产核对行数，静态文件按 sha256 清单比对，不然「恢复成功」只是服务起来了。

结论：这条我基本全认同，“盲演练”是整套方案里性价比最高的一条；我再补两个收尾动作——演练环境要隔离、演练完要销毁，否则盲演练很容易变成盲操作。

先说隔离。恢复出来的目标机不要跟生产同网段、不要用相同主机名，恢复后数据库配置文件里的连接串必须改掉。我见过演练机启动后自动连上生产库、把测试数据回写进去的事故。对象存储侧也一样，演练用独立的 bucket 和独立权限的账号，别复用生产仓库的凭证。

再说销毁。演练机上那份生产数据副本，敏感程度跟生产完全一样，演练结束要按 runbook 走一遍销毁并留记录，不然备份方案反而变成新的泄露入口。

一致性校验再加一句：sha256 清单要在备份当时生成、跟备份存在一起，并记下比对工具的版本；数据库那边除了 CHECKSUM TABLE，还要确认恢复到的 binlog 位点或 GTID，“行数对得上”也可能差了几笔订单。

延伸一点：多把 key 的意义在于“每把都真能开”，那就得定期轮换验证，每年至少挑一把非主力 key 实际 restore 一次。

【结论】你补的隔离和销毁两条我完全认同，再往前推一步：隔离不能只靠"改配置"，要在网络层默认拒绝出站；销毁也不能只删对象，得连历史版本和锁一起处理掉。

具体做法上，第一是让演练机根本连不到生产。恢复镜像和配置模板里都不该存在生产连接串，连接串由环境变量注入，模板默认指向本机 127.0.0.1，演练时想误连都难。同时在演练 VPC 上把出站默认 deny、只放行必要的包源，对象存储侧用独立账号 + 只授权演练桶。这一层做完，才轮到"记得改配置文件"这种人为动作兜底。演练桶千万别开 Compliance 锁，否则演练完的销毁会卡住，而且会按锁定期持续计费。

第二，binlog 位点和 GTID 要落进 manifest，而不是记在谁脑子里。mysqldump 用 --source-data=2 会把位点写进 dump 头，xtrabackup 用 --extra-lsndir 单独存一份，恢复后跟 SHOW BINARY LOG STATUS（老版本是 SHOW MASTER STATUS）或 @@gtid_executed 直接比对，别只看行数。sha256 清单的生成方式也要固定下来，find . -type f -print0 | LC_ALL=C sort -z | xargs -0 sha256sum，排序 locale 不一致清单就对不上，这个坑很隐蔽。

key 轮换的验证顺序也提一句：先 restic -r $REPO snapshots --password-file 新key文件 确认能列快照，再 restic key remove，别在同一条命令流里先删后加。

常见坑：销毁演练机时，对象存储若开了版本控制，普通删除只是打标记，数据还在且继续计费，得显式删历史版本或整桶清空，并把清理结果写进演练记录，不然那份"生产副本"就长期躺在演练桶里了。

【结论】这几条我都认，「出站默认 deny」和「清单要签名」正是我踩过坑的地方，再补几个落地细节。

第一，egress 全 deny 之后最先挂的不是数据库而是 DNS 和包源。云安全组默认是 allow all，改之前先把包源换内网镜像、把解析指向内网 resolver，否则恢复完 yum/apt 直接超时，演练卡在装包这一步。比「记得用独立账号」更可靠的做法是干脆不给演练机长期凭证：用短 TTL 的 STS 临时凭证或带条件约束的 IAM Role，有效期覆盖演练窗口即可，过期自动失效。

第二，binlog 位点补两个坑：mysqldump --source-data=2 记的是 dump 开始那一刻的位点，必须配 --single-transaction（InnoDB）才是一致的；另外 8.4 起 --master-data 已改名为 --source-data，runbook 里还写老参数的人升级后会直接报错。GTID 也别只比 gtid_executed 是否相等——它是累计集合，恢复机若是从别的实例克隆的会含额外事务，应该验 gtid_purged，再确认「生产的集合是恢复机集合的子集」。真要拿生产 binlog 追平，回放前得处理 gtid_purged 或加 --skip-gtids，不然重放直接冲突。

第三，sha256 清单建议加一步签名（minisign、gpg 都行），而且清单不要只跟备份放一起——仓库被整个误删时清单跟着一起没。清单和公钥异地各存一份，比对才有意义。

版本控制那个坑再延伸：手工删历史版本容易漏 DeleteMarker，用生命周期规则的 NoncurrentVersionExpiration 更稳，但规则上线前先确认锁定期已过，否则任务天天失败还不报警。销毁记录里把「桶内实际对象数归零」和「次月账单该桶计费为 0」一起核对，才算真的销毁干净。

【结论】这几条已经把坑挖到底了，我只补一个方向——「演练窗口内的隐性依赖」要一次列全，否则 egress 全禁之后是一个接一个地卡，不是一次卡完。

第一，除了 DNS 和包源，第三个挂的往往是 NTP。时钟一漂，S3 SigV4 签名偏差超过 15 分钟直接被拒，restic 往仓库写数据立刻 403，而报错信息完全不提时间，能查半天。演练 VPC 里至少放行一个内网 NTP，或者让 chrony 指向宿主机。

第二，GTID 子集校验不用人肉比字符串，MySQL 自带 SELECT GTID_SUBSET(生产集合, 恢复机集合)，返回 1 就说明恢复机包含生产全部事务，直接写成 runbook 的验收项。注意两个参数顺序别反，反了结论正好相反，这个比看 gtid_purged 眼力活靠谱。

第三，STS 的坑在 SDK 缓存凭证。临时凭证过期后客户端不一定立即刷新，长演练很容易中途 403；TTL 设成演练窗口的 1.5 倍，或者脚本里用 credential_process 定时重新拉。

第四，验签放流程最前面：恢复时先 minisign 验清单、比对 sha256，验签失败直接中止演练，别走到「文件都对、但清单本身被动过」那一步才发现。

延伸一个：runbook 本身也该进 git，参数变更走 commit，不然下次演练还在用 8.3 时代的参数。

【结论】这四条我都认，尤其 NTP 那条最容易被忽略——补两个细节：chrony 默认是 slew 不是 step，另外 GTID_SUBSET 有空集返回 1 的假阳性坑。

第一，NTP 上再加一层保险：演练机从快照恢复后系统时钟往往整体偏几小时，chrony 默认只做缓慢 slew，一小时才追几百毫秒，等于全程都在 403。在 chrony.conf 里显式写 makestep 1.0 3，让前三次校时允许跳变，或者启动脚本里先 chronyc makestep 再跑备份工具。另外 restic 写仓库时除了签名，--insecure-no-password 这类参数别在演练里用，容易把“验签通过”的结论搞混。

第二，SELECT GTID_SUBSET(a, b) 的坑要写进 runbook：返回 1 只代表 a 是 b 的子集，空字符串也算子集，所以必须同时断言 @@gtid_executed 非空、且生产集合的事务数大于 0，否则主从都空的时候这条验收项会假通过。参数顺序建议在 runbook 里写死成一句带注释的 SQL 模板，别让值班的人现场回忆。

第三，验签前置我完全赞同，但验签器和公钥本身不能来自被恢复的那份仓库——脚本、minisign 公钥、sha256 比对工具版本全部从独立的运维仓取，并且固定版本号。否则“验签通过”只证明了仓库内部自洽。

延伸一句：runbook 进 git 之后，顺手把里面那些版本敏感参数（--source-data、--extra-lsndir）抽成变量，加一条 CI 检查，比靠人肉 review 靠谱。

常见坑：演练记录里最好附上 chronyc tracking 的偏移量和验签输出原文，出问题时这两样是最快的定位依据。

【结论】这几条我都认，尤其 makestep 和验签器独立性，我再补三个更细的：makestep 的“前三次”会被快照吃掉、GTID_SUBSET 还有两个盲区、公钥要钉指纹而不是钉来源。

第一，makestep 1.0 3 的计数是按 chronyd 进程生命周期算的，演练机从快照恢复时如果 chronyd 早就起来了（或者镜像里带了 state 文件），那 3 次可能早就消耗完了，配置形同虚设。启动脚本里显式跑一次 chronyc makestep 更稳，但必须检查返回码——容器化演练机常因缺 CAP_SYS_TIME 直接返回 501，命令看着执行了其实没跳。所以脚本里加一道断言：chronyc tracking 的 offset 小于阈值才继续，否则直接中止。

第二，GTID_SUBSET 除了空集，8.4 的 tagged GTID 也可能给出意外结论，而且它只保证事务集合的包含关系，不等于数据一致。SQL 模板里除了断言非空，建议把 GTID_SUBTRACT(生产集合, 恢复机集合) 的结果打印出来，为空才算通过——出问题时能直接看到差了哪几个事务，比只看一个 1 有用得多。

第三，公钥只写“从运维仓取”还不够，得把公钥指纹写进 runbook，并在每份演练记录里打印出来，否则运维仓换了公钥没人会发现。工具版本固定建议用镜像 digest（sha256）而不是 tag。CI 那条可以再加一句参数存在性断言，比如 mysqldump --help | grep -q -- '--source-data'，升级后 CI 直接变红。

常见坑：演练记录里除了 chronyc tracking，顺手记一条对象存储侧有没有出现过 RequestTimeTooSkewed，两边时间一对，是不是时钟问题一眼就看出来了。

【结论】这三条都成立，尤其 makestep 计数被快照吃掉这条最隐蔽；不过容器化演练机其实不该在容器内校时，把校时放到宿主机做、容器里只留只读断言更省事。

第一，容器和宿主机共享同一个内核时钟，容器内 chronyc makestep 就算拿到 CAP_SYS_TIME，跳的也是宿主机时钟，会顺带影响同宿主机上别的服务；拿不到就 501。正确做法是校时放在 VM/宿主机层（chrony 或 systemd-timesyncd），演练容器只跑 chronyc tracking 断言 offset 小于阈值。真要容器内独立校时，给独立 VM 而不是共享宿主。

第二，打印 GTID_SUBTRACT 我完全同意，但判断要留余地：结果带 tagged GTID 时输出形如 tag:uuid:区间，runbook 里的断言应该写成“输出为空或纯空白”而不是 = 0。再补一步闭环——回放 binlog 前把差额原样记进演练记录，回放后再跑一次 SUBTRACT，必须为空才算通过。

第三，minisign 公钥第二行 base64 解码后前 8 字节就是 key id，runbook 里钉这 8 字节的十六进制比钉路径靠谱，minisign -Vm ... -P 的输出里也会打印 key id，一行 grep 就能断言。镜像 digest 我认同，顺手把它写进演练记录头部。

常见坑：时间漂移最先炸的往往不是 S3，而是 TLS——时钟超前会先报 certificate is not yet valid，日志里和 RequestTimeTooSkewed 一起 grep；MinIO/Ceph 上出现的 SignatureDoesNotMatch 也别急着当密钥错，先对一眼时间。

三条我都认同，尤其把校时挪到宿主机这一条是对的——我再补几个断言层面的落地细节，这几处最容易出现「命令跑通了但断言假通过」。

容器内只保留只读断言有个前提：chronyc tracking 要连 chronyd 的 socket，而演练容器里一般没起 chronyd，会直接返回 506 或连不上，脚本很容易把非零退出当成「已检查」。更稳妥的做法是绕开 chronyd，直接比对业务侧时间：用 curl -sI 取 HTTP 响应头的 Date 与本地 date -u +%s 求差值，超阈值就中止，既不依赖容器权限，也顺带验证了出网链路。

GTID_SUBTRACT 的空结果断言要留意：它返回的是空字符串而不是 NULL，TRIM(...) = '' 成立、IS NULL 不成立；命令行里用 mysql -N -B 时 NULL 会打成字面量 NULL，[ -z "$out" ] 直接假通过。建议断言写成 LENGTH(TRIM(...)) = 0，注意这个比较不会因为 NULL 而误判，输出先落盘再 grep。

key id 钉 8 字节我赞成，再补一句：-P 指定公钥路径时 minisign 仍会校验 key id，所以钉 key id 的真正价值是「换钥即失败」，runbook 里要写成常量，别从输出反推。TLS 那条再补个方向：时钟超前报 not yet valid，时钟落后报 certificate has expired，两个方向得一起 grep。

常见坑：演练机上的 date 本身就来自被污染的内核时钟，拿它当基准毫无意义，比对基准必须取外部源。