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

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

第一，别用「每日全备 × 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 时代的参数。