一、搬家这件事的真相：99% 的风险在切换那 5 分钟
多数人以为搬家难在「数据怎么搬过去」，实际上搬数据是最简单的一步——rsync 加个参数就是几小时的自动任务。真正会出事的是切换那一刻：DNS 记录改了，但全球各地递归 DNS 服务器的缓存还没过期，流量还在往老机器上打；老机器上进程已经停掉，访客看到的是 502；如果你没有预留足够的 TTL，等于让全球用户陪你一起等缓存过期。
第二个被低估的风险是「搬完发现不对」。新机器上跑起来了，看起来能访问，但某个后台任务没起来、某个定时任务没同步、某个环境变量漏了。你以为迁移完成了，实际上三周后才发现报表数据一直在丢。
第三个风险是 IP 变更带来的连带影响。备案过的网站、绑定了支付回调白名单的接口、第三方 webhook 的回调地址、监控告警的接收端——这些都需要单独更新，其中任何一项漏了，都是「网站能访问但功能不正常」的静默故障。
第四个风险是 IP 信誉归零。新机器是全新 IP，之前积累的任何信誉记录都不存在。如果你的业务依赖 IP 信誉（比如发信、爬取、API 调用频率限制），搬家意味着从零开始。
所以本文的写法是：把风险点全部显式列出来，每一步都给出「什么情况下算成功」的数字标准，而不是笼统地说「同步完就切」。
二、第一步：迁移前的资产盘点
搬家前必须有一份完整清单，否则你只会搬走你记得的那部分。
第一步是列出所有跑在这台机器上的东西：
# 1. 监听中的服务与端口
sudo ss -tulnp
# 2. systemd 服务清单
systemctl list-units --type=service --state=running | grep -v "systemd\|dbus\|sshd\|cron\|getty\|polkit\|network\|udev\|resolved\|accounts"
# 3. crontab 定时任务
sudo crontab -l
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
# 4. 容器与编排
docker ps -a 2>/dev/null
docker volume ls 2>/dev/null
docker-compose ls 2>/dev/null
kubectl get all 2>/dev/null
# 5. 站点目录与数据库
sudo du -sh /var/www/* 2>/dev/null
mysql -e "show databases;" 2>/dev/null
sudo -u postgres psql -l 2>/dev/null第二步是记录环境与配置。这一步最容易被漏，但往往是搬家后跑不起来的直接原因：
# 环境变量与密钥
sudo cat /etc/environment
env | sort > ~/old_env.txt
sudo ls -la /etc/default/ /etc/sysconfig/ 2>/dev/null
# 密钥文件
sudo ls -la /root/.ssh/ ~/.ssh/ /etc/ssl/private/ 2>/dev/null
# 定时任务的完整内容（不只是 crontab）
sudo crontab -l > ~/old_cron.txt
# 已安装的包
dpkg --get-selections > ~/old_packages.txt第三步是找出所有指向这台机器 IP 的外部依赖。这是最容易漏、后果最严重的一类：
- 域名 A 记录和子域（dig +short 你的域名）
- CDN 的源站配置与回源 HOST
- 第三方 webhook 回调地址（支付、IM、邮件、监控）
- 支付平台的白名单 IP
- OAuth 应用的回调地址
- 监控告警的接收端与探针地址
- VPN 客户端的服务器地址
- 数据库连接串（其他机器直连你的数据库）
- 定时任务从别的机器 pull 你的数据
把这张表做成一张 Excel，每一项后面写上「已更新 / 待更新 / 不涉及」，搬家过程中逐项打勾。量化验收阈值：清单里的每一项最终都必须是「已更新」或「不涉及」，不存在「待更新」。
第四步是量一下要搬的数据有多大：
sudo du -sh /var/www/your-site
sudo du -sh /var/lib/mysql/ 2>/dev/null
df -h /var/www/数据量直接决定同步方式：1GB 以内可以打包传输，超过 10GB 就必须走增量同步，而且要预留足够的磁盘空间（新机至少要有数据量 2 倍的空闲盘，因为迁移期间新旧两份同时存在）。
三、第二步：数据同步的三种方案
方案 A：rsync 增量同步——适用于文件类数据，是最常用的方案：
# 第一次全量
rsync -avz --delete \
--exclude='*.log' --exclude='cache/' --exclude='node_modules/' \
-e "ssh -p 你的端口" \
root@旧机IP:/var/www/your-site/ /var/www/your-site/关键参数解释：--delete 会删除目标端源端没有的文件，用它之前务必先加 --dry-run 跑一遍确认不会误删。--exclude 排除掉日志和缓存目录，能省下大量时间和带宽。-z 启用压缩，对文本类文件（HTML、JSON、源码）效果明显，压缩率通常在 3 到 4 倍；对已经压缩过的文件（二进制、图片）几乎没有收益，反而增加 CPU 占用。
第二次同步时去掉 -z（数据已经同步过一次，再压缩意义不大）：
rsync -av --delete --info=progress2 \
-e "ssh -p 你的端口" \
root@旧机IP:/var/www/your-site/ /var/www/your-site/方案 B：数据库单独导出导入。数据库不能直接 rsync 目录，必须用逻辑备份：
# MySQL 导出
mysqldump --single-transaction --quick --routines --triggers \
--default-character-set=utf8mb4 \
-u root -p yourdb > /tmp/dump.sql
# 传到新机
scp -P 你的端口 /tmp/dump.sql root@新机IP:/tmp/
# 新机导入
mysql -u root -p yourdb < /tmp/dump.sql--single-transaction 是 InnoDB 表的一致性快照，不锁表，这是生产环境必须加的参数。--quick 让 mysqldump 逐行读取而不是一次性载入内存，大库不会把内存撑爆。
PostgreSQL 用 pg_dump：
pg_dump -Fc yourdb > /tmp/dump.dump
pg_restore -d yourdb /tmp/dump.dump方案 C：最终同步（停机窗口内）——这是整个流程里唯一需要停机的一步：
# 停旧机上的写入（nginx 保持运行，只是不再接受新的写请求）
sudo systemctl stop your-app.service
# 最终 rsync，只传差异
rsync -av --delete --info=progress2 -e "ssh -p 你的端口" \
root@旧机IP:/var/www/your-site/ /var/www/your-site/
# 数据库最终增量
mysqldump --single-transaction --quick -u root -p yourdb | ssh -p 你的端口 root@新机IP "mysql -u root -p yourdb"量化验收阈值：停机窗口内最终 rsync 的传输量应低于总数据量的 5%（因为增量同步已经做完了），且整个最终同步过程在 10 分钟内完成。如果最终同步还在传大量数据，说明前面的增量同步没做对，需要回去检查。
四、第三步：新机器上的环境重建
数据搬过来只是第一步，新机器上的运行环境必须完全对齐旧机，否则会出现「文件在但跑不起来」。
PHP 版本必须一致：
php -v
# 新机装对应版本
sudo add-apt-repository ppa:ondrej/php -y
sudo apt install -y php8.1 php8.1-fpm php8.1-mysql php8.1-mbstring php8.1-curl版本不一致是「500 错误」的头号原因。旧机装的是 8.1，新机装了 8.3，那么旧代码里被废弃的函数就会直接抛错。
扩展模块要逐个对齐。用这个命令列出旧机的完整扩展清单：
php -m | sort > ~/old_php_modules.txt
# 新机上
php -m | sort > ~/new_php_modules.txt
diff ~/old_php_modules.txt ~/new_php_modules.txtdiff 输出为空才算环境一致。常见的缺失项是 redis、imagick、opcache、sodium。
Python 依赖用 requirements 文件：
pip3 freeze > requirements.txt
# 新机
pip3 install -r requirements.txtNode 项目同理：
# 保留 lock 文件，不要删
npm ci # 而不是 npm install，前者严格按 lock 安装服务配置与 systemd 单元：
# 拷贝服务定义
scp -P 你的端口 /etc/systemd/system/your-app.service root@新机IP:/etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable your-app.service
sudo systemctl start your-app.service配置文件的路径依赖是另一个坑。很多程序在配置里写了绝对路径：
sudo grep -rn "/var/www/old-site\|/opt/old-app" /etc/ /home/ 2>/dev/null | head -20把旧路径全部找出来改成新路径，比事后排查「文件明明在却读不到」高效得多。
量化验收阈值：新机上 curl -I http://127.0.0.1/ 返回 200；diff 旧机与新机的 PHP 模块清单无差异；systemctl status 所有服务均为 active (running)；sudo grep -rn "旧路径" /etc/ 无匹配。
五、第四步：DNS 切换与 TTL 陷阱
DNS 切换是整个搬家流程中技术含量最低、但最容易造成长时间故障的一步。核心只有一个概念：TTL（Time To Live）决定了你有多少回旋余地。
TTL 的含义是：这一条解析记录在各级递归 DNS 服务器上最多可以缓存多久。所以切换前必须先降 TTL，等旧 TTL 完全过期，再做真正的切换。
标准的降 TTL 操作流程：
# 1. 提前 24 小时把 TTL 降到 60 秒
# 在 DNS 服务商后台把 A 记录的 TTL 从默认的 3600 改成 60
# （也可以直接用 dig 查询当前值）
dig +noall +answer 你的域名 A2. 等 24 小时，让所有递归服务器上缓存的旧 TTL（3600 秒）自然过期。这段等待时间是必要的，跳过它会导致切换后仍有大量流量打向旧 IP。
3. 切换 A 记录指向新 IP，TTL 保持 60 秒。
4. 观察期至少保留旧机 24 小时。旧机不要关停、不要卸载服务，只是停止写操作。这样万一有问题，切回旧 IP 只需要改一次 DNS，60 秒生效。
如果你的域名不在自己手里（用的是第三方托管、或者域名在别家），提前联系客服确认切换流程和生效时间。有些服务商的 DNS 生效需要几小时，这段时间必须算进计划。
CDN 场景要额外小心。如果你用了 CDN，切换不只是改源站 IP：
- 要先在 CDN 后台把源站 IP 改成新 IP
- 刷新预热缓存，否则新 IP 上没有缓存，首次访问会回源很慢
- 检查 CDN 的回源 HOST 头是否需要同步改
- 部分 CDN 有「源站 IP 变更冷却期」，改完之后短暂返回 521 是正常现象
量化验收阈值：
- 从切换前 30 分钟开始，用 dig +short 你的域名 @8.8.8.8、@1.1.1.1、@223.5.5.5 分别查询，返回的 IP 应全部一致且指向新机
- 观察期内累计 5xx 错误率应低于 0.1%
- 旧机的访问日志（tail -f /var/log/nginx/access.log）在切换后 5 分钟内应基本停止增长，10 分钟后应完全无新增
六、第五步：回滚方案必须提前写下来
「回滚方案」不是出事了再想，是在切换前就写好的一张纸。没有预案的迁移叫赌博。
回滚触发条件要量化，提前定好，避免到时候凭情绪决策：
| 触发条件 | 判定方式 | 动作 |
|---|---|---|
| 新机服务启动失败 | systemctl status 非 active 超过 3 分钟 |
立即回滚 |
| 5xx 错误率超阈值 | 监控面板 5 分钟内 5xx ＞ 1% | 立即回滚 |
| 数据写入异常 | 数据库写入报错或数据对不上 | 立即回滚 |
| 关键功能不可用 | 支付/登录任一流程手工测试失败 | 立即回滚 |
| 响应时间劣化 | P95 比旧机基线高出 50% 以上且持续 10 分钟 | 评估后回滚 |
回滚动作本身要预先演练过。回滚不是「改回 DNS 就完事」，而是一整套动作：
# 1. 恢复旧机服务（如果之前停了）
sudo systemctl start your-app.service
# 2. 把 DNS 改回旧 IP（TTL 已是 60 秒，60 秒内生效）
# 3. 如果这期间有数据写在新机，需要把新机的增量数据导回旧机
mysqldump --single-transaction --quick -u root -p yourdb | ssh -p 端口 root@旧机IP "mysql -u root -p yourdb"
# 4. 验证旧机已接收最新数据关键细节：回滚时的数据处理方向和正向迁移相反。如果切换后有用户在旧机写了数据（如果旧机还在跑），或者新机写了数据，都需要合并。这一步如果没提前想好，回滚会变成「恢复服务但数据不一致」的状态，比不回滚更糟。
保留窗口要定死。建议：旧机在切换后保留 7 天，期间只读不写（或接受写入但每日同步回旧机）。7 天之后，确认新机稳定、旧机可安全释放。这期间旧机的成本通常不高，但它买的是「随时能退回去」的权利。
七、停机时间能压到多短
停机窗口的长度取决于两件事：数据增量和你的业务能不能接受只读。
场景 A：纯展示型网站（博客、文档站）。可以在切换时直接把旧机的服务停掉，同步最后增量，改 DNS。这种情况下停机窗口 = 最终 rsync 时间 + 数据库导入时间。如果增量控制在 5% 以内、10GB 以内的数据量，窗口通常在 2 到 5 分钟。
场景 B：带后台的网站。可以用「写入冻结 + 最后同步」的组合，窗口 3 到 10 分钟。
场景 C：有实时写入的业务（订单、IM、API 服务）。要做到零停机需要双写，架构如下：
用户 → 负载均衡/新机（主）
↓ 异步复制
旧机（热备，始终运行）具体做法：
# 双写期间旧机保持运行，把新机的写入反向同步回旧机
while true; do
mysqldump --single-transaction --quick -u root -p yourdb \
| ssh -p 端口 root@旧机IP "mysql -u root -p yourdb"
sleep 60
doneDNS 切换后，让旧机继续跑 24 到 48 小时，期间新机的数据每分钟反向同步回旧机。一旦发现问题，把 DNS 切回旧 IP 即可，业务立刻恢复，且数据不丢。
零停机的代价要算清楚：双写期间的旧机成本是双份的（通常 2 倍月费的一部分），加上每分钟一次 dump 的 CPU 和带宽消耗。如果你的业务价值低于这个成本，直接接受 5 分钟的停机窗口更划算。
量化验收阈值：
- 停机窗口：展示型 ≤ 5 分钟，带后台 ≤ 10 分钟
- 停机期间的首字节时间（TTFB）从切流到恢复，间隔不超过 90 秒（DNS 60 秒 TTL + 生效延迟 30 秒）
- 切换后零数据丢失：切换前后的订单数、注册数、提交数总和必须完全一致，用 SELECT COUNT(*) 前后比对
八、搬家前后的性能对比：别搬完就以为更快
搬家的一个常见心理预期是「换到新机器性能就变好了」。但真正影响访问速度的是网络路径，不是 CPU。
搬家前后必须做同一套基线测试，才能知道是不是白搬了：
# 1. 从国内网络测 TCP 握手与首字节（用外部节点）
# 在多地拨测点执行，或用第三方测速工具
curl -o /dev/null -s -w "connect: %{time_connect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://你的域名
# 2. 服务器本地回环测试（排除网络因素，纯看机器）
curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s\n" http://127.0.0.1/
# 3. 带缓存未命中模拟
curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s\n" "http://127.0.0.1/?nocache=$(date +%s)"机器本地的量化验收阈值：
- 首字节时间（TTFB）＜ 300ms
- 1MB 静态文件本地下载 ＜ 2s
- 内存使用率谷值 ＜ 15%（长期运行的业务机器）
- CPU 空闲时负载均值 ＜ 0.3
- 磁盘剩余空间 ＞ 30%
外部访问的量化验收阈值：
- 国内三地拨测的 TTFB 中位数 ＜ 300ms
- 晚高峰时段（20:00–23:00）TTFB 不超过白天基线的 2 倍
- 30 分钟内 0 次 DNS 解析失败
如果搬家后 TTFB 没有改善，问题多半出在：两台机器的机房和你的用户不在同一区域（新机离用户更远了）；新机是不同商家的不同网络（路由质量变了）；或者瓶颈从来不是服务器而是应用层（数据库慢查询、第三方接口慢）。
九、迁到日本哪个档位：把成本算清楚再决定
搬家的时候顺手换配置是最自然的想法，但换到哪一档是个算术题。我们用渠道库里真实的日本套餐价格来算。
先看 JUSTG 在售的 RosCloud 系列月付档位（数据来自渠道库 2026-11-06 快照）：
| 机型 | 月价(美元) | CPU | 内存 | 硬盘 | 月流量 | 每GB内存 | 每GB硬盘 | 每TB流量 |
|---|---|---|---|---|---|---|---|---|
| RosCloud-01 | 19.99 | 2核 | 1GB | 20GB | 1024GB | 19.99 | 1.00 | 19.99 |
| RosCloud-02 | 29.99 | 3核 | 2GB | 40GB | 2048GB | 14.99 | 0.75 | 15.00 |
| RosCloud-03 | 39.99 | 4核 | 4GB | 80GB | 3072GB | 10.00 | 0.50 | 13.33 |
| RosCloud-04 | 49.99 | 5核 | 8GB | 160GB | 4096GB | 6.25 | 0.31 | 12.50 |
| RosCloud-05 | 59.99 | 6核 | 16GB | 240GB | 5120GB | 3.75 | 0.25 | 12.00 |
| RosCloud-06 | 69.99 | 7核 | 24GB | 320GB | 6144GB | 2.92 | 0.22 | 11.67 |
这张表能读出三个关键信息。
第一，单位成本随配置单调下降。 每 GB 内存的成本从最低档的 19.99 美元一路降到顶配档的 2.92 美元，相差 6.8 倍。这意味着「买最低档再自己升级」在经济上永远不划算——你不可能在 VPS 上把内存扩容到 4GB 而不额外付费，反而是把两笔账都付了。
第二，硬盘和流量的边际价格远低于内存。 顶配档的每 TB 流量只要 11.67 美元，每 GB 硬盘只要 0.22 美元。日常建站、跑 API 后端这类场景，流量和硬盘基本用不满，真正的瓶颈永远是内存。
第三，中间档位是性价比拐点。 从 RosCloud-03（每 GB 内存 10.00 美元）到 RosCloud-05（3.75 美元），每 GB 内存成本降了 62.5%，而总价只涨了 50%。这一段是配置增长带来的效率红利区。
那么搬到哪一档？ 用你的实际负载倒推。方法是把现有机器的峰值内存占用乘以 1.5 作为新机的内存需求：
# 看当前机器的内存峰值和日常占用
free -m
ps aux --sort=-%mem | head -10
# 看历史峰值（如果有监控数据）
grep "MemAvailable" /var/log/sysstat/sa22 2>/dev/null | awk '{print $2}' | sort -n | tail -1新机内存 = 历史峰值内存 × 1.5，这是留出缓存和突发余量的经验系数。按这个公式：
- 峰值内存 ≤ 0.6GB → 选 1GB 档（RosCloud-01，19.99 美元/月）
- 峰值内存 1.3–2.0GB → 选 2GB 档（RosCloud-02，29.99 美元/月）
- 峰值内存 2.6–4.0GB → 选 4GB 档（RosCloud-03，39.99 美元/月）
- 峰值内存 5.3–8.0GB → 选 8GB 档（RosCloud-04，49.99 美元/月）
量化验收阈值：新机上线后连续运行 7 天，free -m 显示的内存使用率谷值应 ＜ 15%（即预留了 85% 的空闲），峰值不超过 60%。如果峰值超过 60%，说明档位选小了，应该再往上一档；如果长期谷值低于 5%，说明买大了，可以退回一档省下钱。
把停机成本也算进来。假设你的业务每小时的毛利是 X 元，那么停机 10 分钟的代价是 X/6。把这个数加到迁移的一次性成本（人力 1–2 小时 + 可能的双机并行费）上，再和年付相比月付节省的钱比较。年付套餐的折月价通常明显低于月付——以 sixtynet 的年付机型为例，LAX-STARTER 是 200 美元/年，折合 16.67 美元/月，折算下来相当于打了八折左右。你要回答的问题是：我至少要在这台机器上待满多少个月，年付才划算？ 公式是：月付总额 × N ≥ 年付总额 时 N 才是临界月数。
还有一个常被忽略的项：迁移期间的流量成本。 如果你的月流量在 4096GB 这一档已经接近上限，搬到同档位的机器后任何一次流量尖峰都会触发限速或者额外计费。商品库里云途的套餐就明确列出了流量重置价格（traffic_reset_price），香港档位在 200 到 500 元之间不等——这说明超流量是要单独付费的。选档位时，月流量至少要留出 30% 的余量，否则一次爬虫抓取或者一次被刷的接口就能把你的带宽吃光。
十、什么情况下不该搬家
搬家不是越多越好。以下几种情况，搬了反而更糟，判断依据全部是公开的技术事实。
场景一：你的主要用户在中国大陆，而两台机器都在日本。 中日之间的国际出口带宽是共享且拥塞的，跨机房搬家不会改变你走的这条国际链路。从东京 A 机房搬到东京 B 机房，绕路的差异可能只有 1 到 2 毫秒，但整个中日段落的延迟依然是 40 到 90 毫秒。替代方案是：如果速度不满意，正确的动作是把节点换到香港或者中国大陆的边缘节点，而不是在日本境内换机房。
场景二：你搬家的原因是「机器变慢了」，但瓶颈在应用层。 迁移本身不会让慢查询变快，也不会让臃肿的 PHP 代码变快。如果你的 MySQL 有没有走索引的查询，单条 SQL 就能吃掉全部 CPU，这时把机器换成 8 核也救不了。替代方案是先做慢查询日志分析（SHOW SLOWLOG 或 pt-query-digest），把缺失的索引补上，再考虑要不要换机器。
场景三：你的业务规模很小，停机成本高于迁移收益。 一个日均几百 PV 的个人博客，迁移一次的人力成本（1 到 2 小时）远超它能带来的收益。替代方案是继续用现有机器，把精力花在内容和技术栈上。
场景四：你需要的是 IP 信誉，而不是更快的机器。 如果你的业务受 IP 信誉影响（邮件送达、流媒体解锁、API 调用频率），那么「搬到另一台机器」和「换一个 IP」是两件事——搬家如果连 IP 一起换，信誉归零；搬家但保留 IP，则不存在这个问题。所以关键问题是：你的服务商是否支持保留原 IP 迁移？这是一个必须在付款前问清楚的产品能力问题。
场景五：你的流量有明显峰谷，且业务对弹性有需求。 VPS 是固定规格，搬家只是换一台固定规格的机器。如果你的真实需求是「高峰扩容、低谷缩容」，替代方案是使用云服务器或按量付费方案，而不是在 VPS 之间反复搬家。
场景六：你打算用「先关旧机再开新机」的方式省一台机器的钱。 这等于放弃回滚能力。一旦新机有问题，你不仅要等 DNS 生效（60 秒），还要等数据从备份恢复（可能几小时）。正确做法是双机并行跑 7 天，多花的钱买的是确定性。
十一、给四类人的具体建议
第一类：个人站长，站点日均几百 PV。 不要迁移。把当前的机器维护好，做好备份（每周一次全量 dump + 对象存储异地存），把精力放在内容上。如果一定要换机器，只在当前机器厂商停止服务或频繁故障时才动，用月付新机、验证正常后再转年付。
第二类：中小型电商或 SaaS，日均 1 万到 10 万 PV，有真实数据库写入。 值得迁移，但必须按本文的流程走完整套：先降 TTL 等 24 小时、增量同步至少跑两轮、切换后旧机保留 7 天。停机窗口目标控制在 10 分钟以内。选型上优先考虑年付套餐的折月价，把预算花在内存上——数据库服务的瓶颈几乎总是内存而不是 CPU。
第三类：做站群或代理业务的，一次要管理 10 台以上机器。 单台手工迁移不划算，必须上自动化。写一个 Ansible playbook 做环境重建，加一个定时 rsync 做增量同步，DNS 切换走批量 API。这样单台迁移的边际成本降到几分钟，可以按业务节奏随时换。
第四类：纯测试环境、随时可以重建的机器。 直接重建最省事。tar 打包传输、导入数据库、改 DNS，整个过程一小时内可以结束，不需要任何回滚预案——反正数据丢了也能重建。
如果你不属于以上四类，按本文第五到第七节的检查清单走一遍，把「回滚触发条件」那张表先填出来再动手。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 zenlayer 当前机型与价格
- 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 justg 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 zgovps 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 景文互联 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十二、常见问题
问：迁移过程中数据量有几 TB 还来得及 rsync 吗？ 答：rsync 本身支持大数据量，但要配合两个参数：--partial（中断后保留半截文件，下次续传）和 --append-verify（追加模式并校验，适合大文件）。真正的瓶颈是网络带宽——按 100Mbps 端口估算，1TB 数据理论最少需要 24 小时，实际会因为大量小文件而慢好几倍。TB 级数据的正确做法是用数据库逻辑备份加底层块级快照，或者直接用对象存储做同步通道。
问：DNS 切换后多久全球都能访问到新 IP？ 答：取决于你的 TTL 和递归服务器的分布。TTL 设为 60 秒的话，主要的公共 DNS（8.8.8.8、1.1.1.1、223.5.5.5 等）通常在 60 秒内更新，但各 ISP 自建递归服务器的缓存刷新策略不一，保守估计 5 到 15 分钟内全球大部分流量会切过来。所以观察期至少留 24 小时。
问：迁移之后网站排名会掉吗？ 答：URL 不变的情况下一般不会大幅波动，搜索引擎会重新抓取并更新 IP 记录。有几个可以做的平滑处理：保持所有页面路径不变（不要借机改 URL 结构）、保留原有的 301 和 302 规则、不要在迁移期间同时改标题和描述、在 Google Search Console 里提交站点地图加速重新抓取。如果迁移时顺便改了 URL，就必须做完整的 301 映射表，那会带来排名的短期波动。
问：旧机和新机应该选同一家商家吗？ 答：不一定，但有个实际考量：如果旧机和新机在同一家且同一机房，网络层通常更稳定，延迟波动更小；如果跨商家跨机房，可能引入新的路由问题，表现为平时正常、晚高峰抖动。另一个考量是故障隔离——同一家商家出问题时两台可能一起挂，跨商家则互相独立。折中做法是：如果原商家续费顺利就留在原商家换套餐；如果对原商家不满意，就换新商家但把旧机保留到观察期结束。
问：怎么验证迁移真的成功了？ 答：跑一遍数据对账脚本，比抽查可靠得多：
# 表数量与行数对账
mysqldump -u root -p --no-data yourdb | grep -c "CREATE TABLE"
# 关键表行数
mysql -u root -p -e "SELECT COUNT(*) FROM orders;" yourdb
# 校验和
mysqldump -u root -p yourdb | md5sum新旧两边跑同一组命令，比对输出。最后一条的 md5 在两台机器上应当完全一致；如果不一致，说明有遗漏的表或字符集问题。
问：迁移期间怎么防止自己把源机误删了？ 答：给自己上一道物理保险——在旧机的根目录建一个提醒文件，或者用 chattr 给关键目录加不可删除属性。最朴素也最有效的做法是：保留旧机至少 7 天，并且在确认新机稳定之前，不在服务商那里注销旧机。注销是物理删除，不可逆；而保留旧机只是每月多付一点钱。
问：Docker 部署的应用怎么迁移？ 答：分四步。第一步导出镜像，docker save yourapp:latest | gzip ＞ yourapp.tar.gz，然后 scp 传到新机。第二步导入镜像，gunzip -c yourapp.tar.gz | docker load。第三步搬数据卷，用 docker run --rm -v 项目名_数据卷:/data -v $PWD:/backup alpine tar czf /backup/data.tar.gz /data 打包，再在新机解包回同名卷。第四步核对 compose 文件里的卷名、网络名、端口映射和镜像 tag 是否与旧机完全一致——容器起不来绝大多数是卷名对不上或者 tag 没跟着一起迁移。
问：迁移时把整个系统目录 tar 打包过去行不行？ 答：技术上可以，实操中不建议。整包搬运会把旧机的网络配置、SSH 主机密钥、网卡名、fstab 里的 UUID 一起带过去，新机器的硬件标识完全不同，容易出现网卡命名错乱（eth0 变成 ens3）导致网络不通。更稳妥的是只搬应用目录和数据目录，系统层用脚本重建——本文第四节讲的就是这个思路。
问：旧 IP 需要保留吗，什么时候问商家？ 答：如果你的业务绑定过旧 IP（支付回调白名单、OAuth 回调、监控探针地址），就必须保留，这时要在付款前确认服务商是否支持「保留 IP 迁移」这个能力，而不是先买新机再问能不能迁。另外注意备案信息：国内主机商家的备案是绑 IP 的，IP 变了备案就失效了，需要重新做备案。虽然日本服务器不需要备案，但如果你的业务体系里有其他国内服务器共享同一套备案策略，这个影响也要算进去。
问：迁完之后发现新机比旧机慢，是迁移失败了吗？ 答：不是失败，是路径变了。按第八节的对照方法，先分离出「机器本机性能」和「外部访问体验」两部分。如果本机 TTFB 从 200ms 变成 600ms，那是机器本身的问题（CPU 被限制、内存不足导致换页、磁盘是机械盘或低速盘）。如果本机 TTFB 没变但外部访问变慢，那是网络路径的问题，通常是新机所在机房到你的用户的路由不如旧机，或者新机有更严格的出口限速。这两种情况的处理完全不同，不要混在一起调。
问：多台服务器一起迁移怎么安排顺序？ 答：先迁依赖最底层的那台（数据库、缓存、消息队列），验证它稳定后再迁依赖它的应用层（后端服务），最后迁最外层（前端、反向代理）。每一层迁完必须跑通健康检查才能动下一层。反过来做的话，上层切过来后发现数据库连不上，回滚复杂度会成倍上升。整体顺序应该从内向外，像拆俄罗斯套娃一样。
问：迁移要留多少回滚窗口？ 答：按业务风险分级。个人博客留 3 天足够；有真实交易的业务留 7 到 14 天；涉及支付回调、账务数据的留满一个完整账期（通常 30 天）。窗口期内的成本计算很简单：旧机月费 × 保留天数 ÷ 30。对 sixtynet 的 LAX-STARTER 这类年付机型，旧机保留成本几乎可以忽略，因为年付已经付过了——这正是年付在迁移场景里的隐藏优势。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
