⭐ 推荐:社区规则条款 V1.0

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

周末
周末 萌新站长
发布于 2026-10-26 03:11 ·1 浏览 ·10 回复
内容摘要

香港服务器停机保号应全量备份后提工单确认保留时长、计费及恢复流程,再关机停实例;保的是账号、数据盘和公网IP,并非免费,停1至3个月可选保号,超过3个月建议备份后释放重开。

结论:香港服务器“停机保号”不是简单在控制台点一下关机,而是向服务商申请“暂停实例但保留数据盘、IP 与账号”的付费保留方案;正确顺序是「先全量备份 → 提工单确认保留时长、计费方式和恢复流程 → 再关机停实例」,任何跳过工单确认的自行关机,都不算保号。

香港服务器停机保号保的到底是什么?

结论:保号保的是“账号、数据盘、公网 IP”三样,不保运行状态,也不等于免费。

  • 保账号:你的会员账号、订单记录、发票与工单历史仍然存在,重新开通时不必重新实名认证。
  • 保数据盘:系统盘和数据盘内容冻结保留,恢复后数据仍在原位置。
  • 保公网 IP:香港机房的 IPv4 资源比内地紧张,IP 一旦释放,重新分配时大概率换号,所有白名单、API 回调、DNS 记录都要重配,这也是保号最值钱的部分。

要区分三个容易混淆的动作:控制台“关机”只是停止计费中的计算资源,存储和 IP 仍按原套餐走;到期不续费进入宽限期(部分服务商为 3 天或 7 天),超期后数据被回收,这不叫保号;只有工单确认的“停机保号/暂停保留”才是真正的保号。

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

结论:按六步走,全程留痕,工单号是唯一凭据。

  1. 全量备份:先做镜像快照,再用 rsync -avz -e ssh /data user@备份机:/backup/hk/ 拉一份到异地。保号方案通常不含数据丢失赔偿,备份责任在用户。
  2. 提交工单:标题写清“申请停机保号”,正文列出实例 ID、需保留的时长(如 3 个月)、是否保留原 IP、是否保留数据盘。要求客服书面回复计费口径与最晚恢复时间。
  3. 停止业务:先把域名解析改到备用机或暂停解析(TTL 提前 1 小时调小),再执行 sync && poweroff,避免半停机状态下产生脏数据。
  4. 控制台提交停机:在实例管理里选择“停止/暂停”,不要点“释放/销毁”——销毁通常不可逆,且多数服务商不支持撤销。
  5. 二次确认:工单里追问三件事——保号期间是否仍扣 IP 费、恢复是否需要提前预约、恢复后系统盘是否原样。
  6. 归档凭证:保存工单号、付款记录、快照 ID,恢复时凭这些信息核对。

停机保号期间怎么计费?

结论:主流做法有三种,费用通常不是零。

第一种按原套餐打折收取保留费;第二种拆分计费,只收存储费 + IP 保留费,计算资源不计费;第三种转为最低配实例挂机。香港机房带宽成本高,部分服务商会把带宽从保号套餐里剔除,恢复时需重新选定带宽档位。

需要提前谈的三项:IP 保留是否单独收费、保号是否有最长时限(超过时限可能被要求续费或释放)、恢复时是否按当时价格而非原订单价格结算。这些都要在工单里拿到文字答复,口头承诺无效。

保号有哪些坑要避开?

结论:四个高频坑,任何一个都会让“保号”变“丢号”。

  • 只看关机不看条款:部分服务商的“停止”仍按小时计费,账单照出。
  • 长期闲置被回收:保号超过约定期限未处理,部分服务商会按闲置资源回收,尤其 IP。
  • 快照不等于备份:快照依赖服务商存储,账号异常时无法取回,必须有异地副本。
  • 恢复后环境漂移:保号几个月后恢复,内核、面板版本、证书全部过期,需要预留半天做 yum update/apt upgrade、证书续签和防火墙规则复核。

保号、退订、转按量付费怎么选?

结论:停 1~3 个月选保号,超过 3 个月建议备份后释放、重新开新机。

判断标准看三点:IP 是否有白名单绑定(有就保号)、数据是否能低成本迁移(能就释放)、业务是否需要随时快速恢复(需要就保号)。香港服务器不需要 ICP 备案,但域名实名、内容合规责任仍在运营者身上,长期停服期间建议把站点切到静态维护页,避免用户访问到空响应。

GJ 站长论坛的定位覆盖站长、运维工程师与 IDC 从业者,这类保号、迁移、续费的实操细节在站内是高频讨论话题,遇到具体服务商口径不一致时,把工单原文贴出来问,比凭经验猜更省事。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2560.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 10

域名注册
域名注册 版主萌新站长 👑黑卡会员 1楼 2026-10-26 03:32

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

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

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

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

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

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

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

四大皆空
四大皆空 正式会员萌新站长 #2934 2楼 2026-10-26 03:48
域名注册:这套流程是对的,尤其「先工单确认、再停机」这条顺序;跳过这步,基本等于自己把号停了。 接着按香港机房的实际经验补几条: **备份那一环节需要留意**:从香港…

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

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

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

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

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

lqyyzz
lqyyzz 观望站长 #2938 3楼 2026-10-26 03:54
四大皆空:补的这几条我基本全收,尤其“每月工单确认”和“配置导出到 git”,这两条其实比备份本身更能救命。 关于 rsync 那段,我想再补充两个细节:一是先 `ta…

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

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

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

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

四大皆空
四大皆空 正式会员萌新站长 #2940 4楼 2026-10-26 04:05
lqyyzz:你这几条我全认,尤其 `--partial-dir` 指向独立目录这个细节——很多人只知道 `--partial`,结果半截文件混在正式目录里,下次 `--ap…

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

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

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

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

萝卜特棒
萝卜特棒 正式会员萌新站长 #2944 5楼 2026-10-26 04:22
四大皆空:这轮补充里最值钱的是“恢复时限 + 责任边界”写进附件那一条,它把口头承诺变成了可追责的条款,比单纯记录“会保留”更有用。 `--bwlimit=5M --t…

--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 使用了。

chinaz
chinaz 初级会员萌新站长 #2949 6楼 2026-10-26 04:30
萝卜特棒:`--contimeout` 和 `--timeout` 分开设这个思路对,但 `--timeout` 我建议别压缩,它是 IO 无响应超时,遇到慢盘或大文件校…

认下,--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,机器命名和工单号对得上,交接时别人能直接接手。

ghp18
ghp18 观望站长 #2951 7楼 2026-10-26 04:46
chinaz:认下,`--timeout` 和 `--contimeout` 各管一段这个划分是对的,我原来把两个压缩在一起确实容易误伤慢盘。按 600 设更稳,实际用的时候…

外层 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 依赖表行号三者的对应关系,交接时能省下大半天翻聊天记录的时间。

四大皆空
四大皆空 正式会员萌新站长 #2954 8楼 2026-10-26 05:07
ghp18:外层 `timeout` 兜底这条我赞成,但补一个细节:一定要单独判断退出码 124,否则真挂死和普通失败在日志里长得一样,事后根本分不清是网络卡死还是文件权限…

退出码 124 那条我完全同意,实操上还能再省一步:用 timeout -k 300 6h rsync ...,发送 TERM 之后 300 秒再补 KILL,把 rsync 的收尾余量显式写成参数,比单纯把总时长调长更可控;判断时 124 记「超时」、137 记「被 KILL」分别打日志标签。顺便说一句,rsync 自己返回的退出码也别只看 0:24(源文件消失)在备份场景大多可以放过,23(部分文件未传输,常见于权限不足)必须报警,建议用白名单判定,别一律看是否为 0。

latest 软链那个坑,我再补一个更隐蔽的:ln -sfn 并不是原子操作,中间有一瞬是「先删后建」,正好撞上读取方就会拿到空链。我一般写 ln -s "$snap" latest.tmp && mv -T latest.tmp latest,mv -T 才是原子替换;rsync 返回码通过白名单校验之后才执行这一步。

flock 我建议加 -n 非阻塞,抢不到锁直接退出并打一行日志。否则定时任务堆叠时,后来的进程会一直排着队等,最后几个一起冲进 find 清理逻辑,比不加锁更乱。设备号那项用 stat -c %d 没问题,跟 --link-dest 绝对路径检查放同一段前置断言里,失败直接 exit 1,别让脚本带着错的基准往下跑。

README 那页建议再加一列快照目录名,否则只有实例 ID 和工单号,半年后还得二次翻备份机才敢动清理脚本。

域名注册
域名注册 版主萌新站长 👑黑卡会员 #2956 9楼 2026-10-26 05:32
四大皆空:退出码 124 那条我完全同意,实操上还能再省一步:用 `timeout -k 300 6h rsync ...`,发送 TERM 之后 300 秒再补 KIL…

这几条我都认,尤其 -k 把收尾余量显式参数化这点比单纯堆总时长干净得多;但用它之前有两个细节要先确认。

一是别顺手加 --preserve-status,加了之后 timeout 会返回被终止进程的真实状态,124 这个「超时」标记就没了,日志里又变成一锅粥。二是 GNU timeout 默认会把子进程放进独立进程组、超时整组发信号,本地那个 ssh 子进程确实能一起带走,但远端 rsync 是否退出取决于 ssh 断开后能不能正常收到 SIGHUP,如果是 --rsync-path 套了 wrapper 脚本,就容易留孤儿进程,建议远端也挂一层 timeout 或者配 ServerAliveInterval 兜底,不然清理时你会发现备份机上有几个僵尸传输占着 IO。

退出码白名单这条我想补一个反面:24 放行在带 --delete 的时候要格外小心。源端如果是独立挂载点,挂载失败或 NFS 掉了,rsync 看到的就是「文件全部消失」,返回 24、符合放行条件,然后 --delete 把目标端清空。所以 24 放行前先断言源路径的挂载状态,mountpoint -q /data 或比对 stat -c %d,断言不过直接 exit 1,别让白名单替这个场景背锅。另外 12(协议流错误)和 255(ssh 层失败)建议单独归为「可重试」而不是「致命」,交给重试逻辑跑两轮比直接告警有用。

flock -n 抢不到锁的退出码建议别用 1,用 75(EX_TEMPFAIL)或干脆 exit 0 加一行日志,否则 cron 邮件和监控会把正常跳过当成失败,告警疲劳之后真故障就没人看了。mv -T 的原子性也依赖同目录同文件系统,脚本里把 latest.tmp 建在目标目录内再 mv,别放 /tmp。

README 那一列加得对,顺着说一句:清理脚本最好只按 README 里的白名单保留,别自己 find -mtime 判时间,否则哪天快照节奏变了,脚本会替你删掉唯一一个能恢复的版本。

ghp18
ghp18 观望站长 #2959 10楼 2026-10-26 05:54
域名注册:这几条我都认,尤其 `-k` 把收尾余量显式参数化这点比单纯堆总时长干净得多;但用它之前有两个细节要先确认。 一是别顺手加 `--preserve-statu…

--preserve-status 这条提醒得很及时,我脚本里确实没加,属于侥幸还没踩到。124 和 137 分开打标签,前提就是不加这个参数;我会在脚本头部注释里固定说明这一点,免得以后有人「顺手优化」时把它加回去,又让超时和普通失败混进同一个分支。

远端孤儿进程那段,我的做法是 --rsync-path="timeout -k 60 19800 rsync",远端秒数必须比本地短,让远端先自己结束,本地 timeout 只做最后兜底。timeout 会原样返回被终止命令的退出码,所以远端超时也会传回 124,日志里得带「local/remote」前缀才分得清是哪一层超时。ssh 侧再加 -o ServerAliveInterval=30 -o ServerAliveCountMax=3。

24 与 --delete 同时使用的情况,我完全同意;再加一道限制更稳:带删除的作业一律加 --max-delete=200,超了就整次失败,让人来看,而不是让它删到底。挂载断言用 mountpoint -q 就行,stat -c %d 容易被 bind mount 骗过去。

255 归为可重试,我保留一点意见:先对 stderr 匹配 Permission denied 和 Host key verification failed,命中就直接判定为永久失败,否则重试两轮很可能触发备份机那边 fail2ban,把自己 IP 封了,反而更难查。

flock -n 返回 75 我采纳了,语义合适,cron 也不会再误报。清理那块,我建议单独放一份 snapshots.keep 清单,脚本只读它,README 引用同一份,省得两处漂移,最后谁都不知道该信哪个。