迁移 VPS 到新主机，不停机

三个时钟，以及为什么“零停机”是一个错误的目标#

你离开之后，旧主机商还留着什么#

TTL 时钟，在搬家前一周就开始走#

dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com NS

给新机器选型，以及下单前要检查的事项#

# peak RAM actually in use, not allocated
free -m
# what has been paging, if anything
vmstat -s | grep -i swap
# real disk consumption, biggest first
du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
# load relative to core count
uptime; nproc

分步操作#

1. 提前好几天，先把每条 TTL 都调低

   这一步排在最前面，是因为它是唯一一个有强制等待期的步骤。其余的事情一个下午就能搞定；唯独这一步急不来，跳过它，会把一次五分钟的切换变成一次要等两天的切换。

   登录你的区域文件所在的地方，把每一条会发生变化的记录都设成 300 秒 TTL：顶点 A 记录、AAAA、www、mail，以及其他任何指向 IP 字面量的记录。然后从外部确认一遍，因为控制面板显示的和实际情况有时候对不上：

   dig +noall +answer example.com A @1.1.1.1
   dig +noall +answer example.com AAAA @1.1.1.1
   dig +noall +answer www.example.com A @8.8.8.8

   IN 前面那个数字，就是剩余 TTL。一分钟后再查一次：它应该是从 300 开始倒数，而不是从一个更大的数开始。如果它还在从 3600 倒数，说明旧值还缓存着，你只能等它耗完 — 这正是为什么这件事要在搬家前第七天做，而不是搬家当天早上才做。

   整个迁移期间，以及之后的一周里，都把 TTL 留在 300，这样你的回滚也能又快又稳。等旧机器彻底退场之后，把它改回一个正常的值 — 3600 就挺好 — 就够了。

2. 在拷贝任何东西之前，先给旧服务器做个清点

   你迁移的不是一块磁盘，而是一套正在运行的系统，而人们会漏掉的那些部分，从来都不在 /var/www 里。它们是每月 4 号才跑一次的定时任务，是某次应急处理时临时加的防火墙规则，是两年前从第三方仓库装上的某个软件包。把机器的状态记录成文本，和其他一切一起搬过去：

   mkdir -p /root/mig
   dpkg --get-selections > /root/mig/packages.txt
   systemctl list-units --type=service --state=running --no-pager > /root/mig/services.txt
   systemctl list-timers --all --no-pager > /root/mig/timers.txt
   crontab -l > /root/mig/cron-root.txt 2>/dev/null
   for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/[$u] /"; done > /root/mig/cron-users.txt
   ss -tlnp > /root/mig/listening.txt
   nft list ruleset > /root/mig/firewall.txt 2>/dev/null || iptables-save > /root/mig/firewall.txt
   cp -a /etc/hosts /etc/fstab /root/mig/
   du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -40 > /root/mig/disk.txt

   接下来逐行读一遍 listening.txt，把每一个端口都对上号。这份文件才是“这台服务器到底在干什么”的权威答案，而且结果常常出人意料 — 一个指标导出器、一份被遗忘的 staging 副本、一个原本不该监听公网接口的数据库。

   同时把排除列表也写好，这样第一次同步就不会把一个小时都花在你根本不想要的数据上：

   cat > /root/mig/excludes <<'EOF'
   /dev
   /proc
   /sys
   /run
   /tmp
   /var/tmp
   /var/cache
   /var/lib/apt/lists
   /swapfile
   /var/lib/docker/overlay2
   /var/lib/mysql
   /var/lib/postgresql
   **/node_modules
   **/.cache
   EOF

   注意，数据库目录是被特意排除在外的。它们有自己专属的一步，在这里就把它们拷过去，正是第六步存在的意义所要防止的那个错误。

3. 部署新服务器，在它承载任何东西之前先加固

   下单订机器，选好位置，如果可以的话，操作系统大版本选得和旧机器一样。一边迁移主机、一边把 Debian 12 换成 Debian 13，意味着一旦出问题，你根本分不清是哪个改动导致的。先迁移，再升级。

   在任何敏感数据落到这台机器上之前，先给它做一遍十分钟加固：只用密钥登录 SSH、禁用 root 登录、默认拒绝的防火墙、无人值守的安全更新。现在花十分钟就够了，等服务已经上线运行之后再补做，会真的很麻烦。

   然后在旧服务器上，专门为这次迁移创建一把密钥，这样以后撤销迁移用的访问权限时，就永远不用碰到你自己的登录方式：

   # on the OLD server
   ssh-keygen -t ed25519 -f /root/.ssh/id_migrate -C 'migration' -N ''
   cat /root/.ssh/id_migrate.pub

   把这把公钥放进新服务器的 /root/.ssh/authorized_keys 里，然后确认好传输方向 — 旧机器推送到新机器，这样凭据就留在你即将离开的那台机器上，随它一起报废：

   ssh -i /root/.ssh/id_migrate root@NEW_IP 'hostname; df -h /; free -m'

   最后，把新 IP 写进旧服务器的 /etc/hosts，起个像 newbox 这样的名字。接下来的每一条命令都会因此变短，更有用的是，凌晨一点也不容易再对错机器。

4. 在把任何东西托付给新 IP 之前，先检查它

   你现在有了一个从来没人替你的服务用过的地址，而这是最后一个能免费发现它有问题的时刻。三项检查，五分钟：

   黑名单。拿这个地址跑一遍多个 RBL 检查 — 完整流程和结果解读在这里。命中像 Spamhaus PBL 这样的策略列表，对一个数据中心 IP 来说很正常，对网页流量也基本没什么影响。命中 SBL 或 XBL 才是真的问题，而提出这个问题的时机是现在，不是等你的用户已经用上它之后。

   反向 DNS。查一下这个地址现在的应答是什么：

   dig +short -x NEW_IP

   如果这台机器要发邮件，就去申请你想要的那个 PTR 记录，并确认它对应的主机名，其 A 记录又指回同一个 IP。正向和反向必须一致；对不上，比用一个通用名字还糟糕。

   可达性与路由。从外部确认你需要的端口确实端到端开放，而不是想当然地以为防火墙就是路径上唯一的关卡：

   # from a third machine, or your laptop
   nc -vz NEW_IP 22
   mtr -rwc 20 NEW_IP

   mtr 的输出才是值得留存的东西。最后一跳的丢包才要紧；中间某一跳的丢包，通常只是路由器把 ICMP 降低了优先级，没什么意义。如果从你用户所在地区过来的延迟，明显比旧主机差，最好现在就发现，这时候改主意，代价也就是一份订单，不涉及任何数据。

5. 用 rsync 拷贝文件系统——先跑一次演练

   现在是批量传输。分两轮做：提前好几天先做一次完整拷贝，需要多久就让它跑多久，之后再做几轮短促的增量传输，只搬动发生变化的部分。永远先跑一次演练 — 输出的内容，就是接下来即将发生的事情的确切清单，把它读一遍，比这里任何其他习惯救过的迁移都多。

   # on the OLD server, dry run
   rsync -aHAXx --numeric-ids --info=progress2 --dry-run \
     --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' \
     /var/www/ root@newbox:/var/www/

   然后去掉 --dry-run，跑同一条命令。对每一个重要目录都重复这个过程：/etc 要有选择地拷贝而不是整个搬过去、/home、/srv、/opt，以及你的应用实际存放上传文件的地方。

   这些参数都各有各的用处。-a 保留权限、属主、时间戳和符号链接；-H 保留硬链接；-A 和 -X 携带 ACL 和扩展属性，如果你的上传目录曾经设置过这些，就需要它们；-x 防止 rsync 跑到其他挂载的文件系统里去。--numeric-ids 是最容易被漏掉、事后又最让人后悔的一个：不加它，rsync 会按名字来映射属主，如果 www-data 在两台机器上的 UID 不一样，每个文件到了新机器上都会被归到错误的用户名下，事后理清楚会很麻烦。

   两个警告。把 /etc 整个拷贝到一台正在运行的系统上，会覆盖掉新机器自己的网络配置、fstab 和 SSH 主机密钥 — 只拷贝你需要的那部分具体配置，而不是整个目录。还有，把 --delete 留到最后一轮再用：用它让新机器和旧机器完全对齐是正确的，但如果你已经在目标机器上创建过什么东西，它就是破坏性的。

   第一轮完整传输结束后，比较两边的情况，确认它做的和你以为的一致：

   du -sh /var/www
   ssh -i /root/.ssh/id_migrate root@newbox 'du -sh /var/www'

6. 用转储来搬数据库，绝不要直接拷贝文件

   这一步决定了你的迁移是平淡无奇，还是让人记一辈子。数据库的数据目录，只有在服务器停止运行时才是一致的。带着它在运行中原样拷贝，你会得到一堆看起来没问题、传输起来也没问题的文件，可它们恢复出来的数据库，却带着一种细微而永久的损坏 — 往往要过好几个星期才会报错。

   要老老实实地转储它。对于 MySQL 或 MariaDB，--single-transaction 能在不锁住整个库的情况下，给你一份一致的快照：

   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb \
     | zstd -T0 > /root/mig/appdb.sql.zst

   对于 PostgreSQL，自定义格式很值得一用 — 它会压缩，需要的话还能选择性地恢复：

   pg_dump -Fc -Z6 appdb > /root/mig/appdb.dump

   把它传过去，再恢复：

   scp -i /root/.ssh/id_migrate /root/mig/appdb.sql.zst root@newbox:/root/
   # on the NEW server
   zstd -dc /root/appdb.sql.zst | mysql
   # postgres equivalent
   pg_restore -d appdb -j4 /root/appdb.dump

   然后要验证一下，因为“恢复完成了”和“数据真的都在”，是两个不同的说法。在两边都对比一下要紧的那些表的行数：

   mysql -N -e "SELECT COUNT(*) FROM appdb.orders; SELECT COUNT(*) FROM appdb.users;"

   转储里藏着两个容易被忽略的东西：一个是字符集和排序规则，乱码的重音字符往往就是从这儿来的 — 如果旧数据库用的是 utf8 而不是 utf8mb4，就该有意识地决定，这次搬家是不是也顺便把它修一修；另一个是数据库用户和权限，这些 mysqldump --databases 是不会带上的。要在新机器上显式地重新创建应用要用的用户和密码，然后记得配置里的连接字符串也得跟着对上。

   如果你的应用用的是 SQLite，那个文件就是数据库，同样的规则照样适用 — 不要在它运行时原样拷贝。用 sqlite3 app.db ".backup /root/mig/app.db"，它能安全地生成一份一致的副本。

7. 把技术栈跑起来，借助 hosts 文件覆盖来预演

   新服务器现在已经有了文件和数据。把一切启动起来，在它真实的主机名下测试它 — 这时候全世界其他人还在开开心心用着旧机器。这是整个流程里最有价值的一招，而且只需要一行配置。

   在你自己的笔记本上，把新服务器的 IP 加进 /etc/hosts（或者 C:\Windows\System32\drivers\etc\hosts）：

   203.0.113.10   example.com www.example.com

   你的浏览器现在会把真实域名解析到新服务器，而其他任何人都不会。每一个 URL 都是对的，每一个 cookie 域名都能对上，每一条重定向和回调路径的表现，都会和切换之后一模一样 — 这恰恰是拿一个临时的 new.example.com 子域名去测试所抓不到的问题，因为迁移里出问题的地方，有一半都跟主机名绑在一起。

   如果只是想不改任何东西、快速检查一次，curl 也能就地做到同样的事：

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/
   curl -sS --resolve example.com:80:203.0.113.10 http://example.com/ -o /dev/null -w '%{http_code}\n'

   把整个应用都走一遍，不要只看首页：登录、提交一个表单、上传一个文件、触发一封密码重置邮件、打开一个后台页面、访问一下支付处理商会调用的那个接口。然后哪怕一切看起来都没问题，也去读一遍错误日志 — 缺失的 PHP 扩展、缓存目录上错误的文件权限，还有一个尚不存在的数据库用户，全都会先出现在日志里，然后才会出现在屏幕上。

   事后记得把 hosts 里那一行删掉。所有人都会忘记一次，然后花上二十分钟纳闷回滚怎么看起来没生效。

8. 在翻转任何东西之前，先让新机器上的 TLS 工作起来

   证书绑定的是名字，不是 IP 地址，所以迁移这件事本身，不会让你已经持有的证书失效。会出问题的是签发这个环节：常见的 HTTP-01 挑战，要求 Let's Encrypt 通过 80 端口，去被认证的那个名字上抓取一个文件，而这个名字这时候还指向旧服务器。鸡生蛋、蛋生鸡，难点就在这里，而干净利落的解法有三种。

   直接拷贝现有证书。最简单，通常也是对的做法。私钥和证书链，就像其他文件一样搬过去：

   rsync -aHAX -e 'ssh -i /root/.ssh/id_migrate' \
     /etc/letsencrypt/ root@newbox:/etc/letsencrypt/

   新服务器可以立刻提供有效的 TLS，一旦 DNS 指向它，续期也会自己开始正常工作。确认一下那边的定时器已经启用：systemctl list-timers | grep certbot。

   用 DNS-01 挑战。通过一条 TXT 记录、而不是 HTTP 请求来证明你对域名的控制权，所以哪怕还没有任何东西指向这台服务器，它也能用。如果你想在切换前，就在新机器上拿到一张真正独立的证书，这是理想的选择，也是通配符证书唯一的选择。

   切换之后再签发。可行，但这会留下一段空当：网站已经在新 IP 上运行，却没有证书，对任何用了 HSTS 的站点来说，这不是一个访客能点击穿过去的警告。只有面向一个还没人访问过的全新域名时，这么做才说得通。

   不管你选哪一种，切换之前都要直接对着新 IP 验证一遍，用同样的 --resolve 技巧：

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1
   echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
     | openssl x509 -noout -subject -dates

   检查一下日期，以及证书主体是不是覆盖了你提供服务的每一个名字，包括 www。而且如果你用了 max-age 很长的 HSTS，就该把证书当成翻转之前而不是之后唯一必须万无一失的东西 — 那个响应头，是你已经对每一个回访的访客许下的承诺。

9. 切换：冻结写入、最后一次增量、翻转记录

   真正动手也就十分钟，而且是唯一一段有时钟压着的时间。选在早上做，用你自己的时区，挑一个手头没别的事的日子。绝不要选星期五。

   冻结。把旧应用切换到维护或只读模式。停掉后台工作进程、队列消费者和定时任务 — 所有不经过浏览器就会写入数据的东西。从这一刻起，旧机器上不再写入任何新数据，这也是之后一切操作都安全的前提：

   # on the OLD server
   systemctl stop app-worker.service
   systemctl stop cron
   touch /var/www/maintenance.flag

   最后一次增量。再跑一次 rsync，这次带上 --delete，让目标端完全对齐，再做一次转储。因为第一轮传输早在几天前就完成了，这次要搬的东西很少，几秒钟就能跑完：

   rsync -aHAXx --numeric-ids --delete --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' /var/www/ root@newbox:/var/www/
   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb | zstd -T0 \
     | ssh -i /root/.ssh/id_migrate root@newbox 'zstd -dc | mysql'

   检查。两边核对一下行数，再通过 hosts 文件覆盖，把应用完整走一遍，然后把新机器上的维护标记去掉。

   翻转。把 A 记录改成新 IP。AAAA 记录也要一并改 — 这是切换只做了一半这种情况里最常见的一种。用一个你控制不了的解析器确认一下：

   dig +short example.com A @1.1.1.1
   dig +short example.com AAAA @1.1.1.1

   然后同时盯着两台机器。流量应该会在一两分钟内出现在新机器上，并在接下来的五分钟里从旧机器上逐渐消退：

   tail -f /var/log/nginx/access.log        # on both, side by side

   让旧应用继续留在维护模式，而不是直接关掉它。落单请求碰到它时，看到的会是一个客气的提示页面，而不是连接错误，同时你也留着这台机器，以备你大概率用不上的回滚之需。

10. 观察一周，再妥善下线

    DNS 能解析了，不代表迁移就完成了。真正完成的标志，是一整个计费周期和定时任务周期都平安无事地过去了。

    头几个小时，盯着错误率，而不是在线率 — 一台服务器完全可以处于正常在线状态，同时却把三分之一的请求都返回 500：

    journalctl -u nginx -u php8.4-fpm -f
    awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

    然后按一份简短的清单逐项排查，因为这些才是搬家之后真正会出问题、而且都不会主动吭声的地方：跑在新机器上的定时任务和 systemd 计时器（拿 systemctl list-timers 对照你在第二步做的清点）；外发邮件有没有正常送达而不是进了垃圾箱；定时备份指向的是不是新服务器，而不是还在归档旧的那台；有没有第三方把你的 IP 地址放进了白名单 — 支付处理商、某个 API、合作伙伴的防火墙；还有那个只有到月初才能证明自己是否正常的月度任务。

    让旧服务器继续运行，保持维护模式，不去动它，至少留一周。它是你的回滚方案，也是你的参照副本，比它花的那几美元值钱得多。然后按顺序把它彻底收尾：轮换它可能读到过的每一个凭据，把最后一份加密归档存到第三个地方，覆写应用和数据库目录，跑一遍服务商的销毁或重装流程，最后才取消 — 取消前先看一眼续费日期，因为多花一个月买回滚保险，通常是更划算的选择。

    最后，既然你已经不再需要五分钟级别的可回滚性，就把 TTL 调回 3600，再把你保留的文档更新成新地址。将来某个凌晨两点的你，会因为运维手册和服务器对得上号而由衷感激。

邮件不会跟着其他东西一起搬家#

回滚，但不要让情况变得更糟#

下线收尾：轮换、擦除、核实，再取消#

一份行得通的时间表#

常见问题#