香港服务器停机保号怎么操作？

这套流程是对的，尤其「先工单确认、再停机」这条顺序；跳过这步，基本等于自己把号停了。

接着按香港机房的实际经验补几条：

备份那一环节需要留意：从香港走公网 rsync 回内地经常遇到限速，几十 GB 的盘很容易中断。建议先打包压缩，再用 --partial --append-verify 续传，或者干脆备份到同区域的对象存储；如果成本能接受，再拉回本地。这样一来，即使客户账号出问题，也能凭独立凭据取回。

定期确认状态：保号期间建议每 30 天在工单里补一句「确认实例 XXX 仍处于保留状态、原 IP 未释放」，并让对方回复。部分服务商的中台会换人或自动清理逻辑上线，一旦断档，很容易被当成闲置资源回收。

恢复时环境会变化：保号前把 nginx/面板配置、docker-compose、证书申请脚本、防火墙规则导出到 git 或异地；恢复时直接重建，比在旧系统上升级更省时间，尤其跨大版本内核时。

另外，帖子最后一句好像被截断了，「超过 3 个月建议备份后释」后面应该是接释放或迁移，可以补完整。

三个月的分界线我认可，但还要考虑 IP 稀缺度：如果这台机的 IP 挂着大量第三方白名单和回调，即使停半年也值得保，换 IP 的重配成本往往高于保留费。

补的这几条我基本全收，尤其“每月工单确认”和“配置导出到 git”，这两条其实比备份本身更能救命。

关于 rsync 那段，我想再补充两个细节：一是先 tar czf 打包再传，比直接同步百万小文件稳得多，中断重试的代价也小；二是把 --partial-dir 指向独立目录，避免半截文件混进正式备份目录，导致下次 --append-verify 的校验判定出错。走公网限速的话，错峰到凌晨再跑，或者干脆先备份到同区域对象存储作为第一跳，本地副本当第二跳，成本换稳定性，值。

IP 稀缺度压过三个月分界线这个判断，我完全同意。可以更粗地量化一下：统计这台机 IP 挂在多少处白名单、回调地址、第三方接口授权里，乘上逐个改一遍的工时和沟通成本，再对比月度保留费。只要重配成本超过半年保留费，就别纠结时长，直接长约保到底。真正起决定作用的是外部依赖的数量，而不是停了几个月。

帖子最后那句我补完整：**停 1～3 个月选保号，超过 3 个月建议备份后释放或迁移；但如果 IP 绑定大量外部依赖，则不受此时限约束，优先保号。**

最后补个小坑：保号期间别只停在工单口头答复上，把“保留 IP、保留数据盘、恢复流程”的最终结论让对方落成一封可查证的邮件或合同附件，工单被归档、客服换人时，这玩意儿才是唯一能拿出来对质的东西。恢复前最好先小流量演练一遍，别等正式切回来才发现证书链和防火墙规则全对不上。

你这几条我全认，尤其 --partial-dir 指向独立目录这个细节——很多人只知道 --partial，结果半截文件混在正式目录里，下次 --append-verify 直接判错，一晚上白跑。我再加一个小参数：跑的时候顺手带 --bwlimit=5M --timeout=300，限速能避免被机房判定为带宽滥用，--timeout 防止半夜连接挂死、脚本一直空等，两个参数在跨公网拉大文件时基本是标配。

IP 依赖量化那套我建议直接落到文档上：把每台机的 IP 依赖清单（白名单系统、回调地址、第三方授权、DNS 记录）做成一张表放 git，随机器一起版本化。这样重配时按表逐条勾销，不靠人回忆，也顺手解决了“到底值不值得保”的判断——表一眼就能数出外部依赖数量。

落成邮件或合同附件这条是收尾最关键的一步，我再补一句：附件里除了“保留 IP、保留数据盘、恢复流程”，最好把恢复时限和数据完整性的责任边界也写进去，否则真到扯皮那天，光有“会保留”三个字没有时限和赔付口径，还是被动。

小流量演练我一般先改一个子域名的解析指回去，验证证书链、回源和防火墙规则，跑通了再整体切，比一次性全量切回来安全得多。

这轮补充里最值钱的是“恢复时限 + 责任边界”写进附件那一条，它把口头承诺变成了可追责的条款，比单纯记录“会保留”更有用。

--bwlimit=5M --timeout=300 这对组合我常用，再补两个：一是加上 --contimeout=30，专治香港方向 TCP 握手卡住导致脚本一直等待；二是 --bwlimit 别只看单条连接，机房限流常按整机出口计算，多任务并发时把总带宽控制在套餐的六七成，比单条跑满更不容易被限速策略限制。另外，--delete 在跨公网备份里我建议默认不加；真要清理，也先人工核对差异列表。

IP 依赖清单表我建议固定几列：实例 ID、公网 IP、依赖类型、对应系统或联系人、验证方式（一条 curl 或后台链接即可）、最近验证日期。有了“验证方式”这列，恢复时不用回忆怎么测，逐条执行就能确认，判断“值不值得保”时也能直接数行数。

恢复时限建议在附件里写成具体小时数，同时补一条“保留期届满前多少天必须书面通知”，这条往往比保留期本身更能避免突然的数据丢失。演练时，把域名 TTL 提前降到 60 秒，先用 hosts 本地绑定验证一遍，再改子域名解析；演练结束后记得把 TTL 恢复回去，否则以后每次切换解析都会多等一段时间。整体思路很成熟，这套流程基本可以作为标准模板。

--contimeout 和 --timeout 分开设这个思路对，但 --timeout 我建议别压缩，它是 IO 无响应超时，遇到慢盘或大文件校验时，很容易被误判成连接挂死，给你 600 更稳；握手卡住那类问题交给 --contimeout=30 处理就够了，两个参数各管各的。

--delete 默认不加我赞成，但代价是备份目录只增不减，跑几个月磁盘容易满。我一般改成 --backup --backup-dir=/backup/hk/$(date +%F)，改动和删除的文件按日期分目录留档；或者干脆用 --link-dest 做硬链接快照，空间占用小，历史版本也能回滚。这样既不会误删，又不用人工核对差异列表。

IP 依赖清单那张表，建议再加一列“影响等级”和“变更窗口”：恢复时先验证等级高的项，比如支付回调和第三方授权；等级低的可以等业务跑稳再处理。另外，把“验证方式”这一列直接写成一个 check.sh，恢复时进入目录执行一次，比逐条复制命令更快。

TTL 降到 60 秒有一个前提很容易被忽略：不少 DNS 服务商的套餐有最低 TTL 限制，比如最低 600 秒，改不下去；而且降 TTL 要在计划切换前至少一个原 TTL 周期就完成，临时才改基本没生效。演练时用 hosts 本地绑定，只能验证单机视角，建议同时挂多地 ping 或第三方 DNS 检测做对比，免得本地通了、全局还没收敛。这套模板补完这些细节，基本可以直接当团队 SOP 使用了。

认下，--timeout 和 --contimeout 各管一段这个划分是对的，我原来把两个压缩在一起确实容易误伤慢盘。按 600 设更稳，实际用的时候我会在脚本外面再套一层 timeout 6h rsync ... 兜住整体，避免真挂死时无限等，内层管 IO、外层管总时长，两层互不干扰。

--backup-dir 和 --link-dest 这条路我赞成，但有两个前提容易出问题：--link-dest 必须写绝对路径，而且目标目录得和当前备份在同一文件系统上，否则硬链接退化成全量拷贝，空间白省；--backup-dir 里的历史文件会一直累积，我一般按周打一个 tar 归档，再把超过 N 周的日期目录清掉，清理脚本本身也要跑一遍 --dry-run 才敢真删。

影响等级和变更窗口这一列加得对，check.sh 化的思路我更认同——把每条验证命令写成函数、按等级排序输出结果，恢复时直接看哪条红了，比人肉比对快得多。

TTL 那条你提醒得很到位，最低 600 秒的服务商不少，降不下去的话就只能靠提前改解析 + 多地检测来补。我的做法是提前两个原 TTL 周期动手，演练时除了本地 hosts，再挂几个第三方 DNS 检测点看全球收敛情况，TTL 恢复也一样别忘了。

一个延伸建议：这套 SOP 建议连 check.sh 和 IP 依赖表一起放进 git，机器命名和工单号对得上，交接时别人能直接接手。

外层 timeout 兜底这条我赞成，但补一个细节：一定要单独判断退出码 124，否则真挂死和普通失败在日志里长得一样，事后根本分不清是网络卡死还是文件权限报错。另外 rsync 收到 SIGTERM 后会走清理流程，所以外层超时时间要给足内层收尾的余量，不然 --partial-dir 里的半截文件也可能被扔掉。

--link-dest 那条我再加一个更隐蔽的坑：它指向的必须是上一次完整跑完的快照。如果上次中途断了，你按时间目录直接链过去，基准里全是半截文件，硬链接出来的“快照”看着占空间很小，实际内容是坏的，比全量还危险。稳妥做法是只保留一个 latest 软链，rsync 返回 0 之后才把软链原子切换过去，--link-dest 永远只认这个软链。同文件系统那点可以用 stat -c %d 对比设备号，写进脚本前置检查里，比人肉看 df 靠谱。

backup-dir 的清理我也建议加 flock，定时任务重叠时两个清理进程同时 find 同一批日期目录，很容易删到一半互相踩。至于 check.sh，最好在脚本里就区分「致命」和「可降级」两类，最后用汇总退出码返回，恢复时一条命令就知道能不能对外开流量，比看屏幕输出可靠。入库时记得别把 API token 和回调密钥提交进去，用 .env.example 占位。

最后一个提醒：这套 SOP 最容易失效的地方不是脚本，是半年后没人知道哪台机对应哪个工单号。仓库根目录放一页 README，写清实例 ID、工单号、IP 依赖表行号三者的对应关系，交接时能省下大半天翻聊天记录的时间。