导读：换VPS的理由五花八门：商家跑路前兆、年付到期涨价、手头机器配置不够、发现更优线路。但很多人宁可忍着也不搬，怕的就是两件事：数据丢了、切换瞬间网站打不开。这篇把搬家这件事拆成一条流水线：盘点、备份、传输、数据库、切换、验证、回滚，七个环节每个都给出具体命令。照着做完，停机窗口能压到几分钟，出问题随时回退，全程心跳不加速。本站之前讲过备份策略和商家跑路征兆，这篇是它们的“行动篇”——真到要搬的那一刻，照单执行。
一、搬家前先盘点：你到底在老机器上跑了什么
搬家的第一坑不是技术，是遗漏。跑了一两年的机器，上面散落的东西往往比记忆里多。SSH上去，花十分钟做一次全面盘点，输出一张“资产清单”。
第一，跑着哪些服务：
systemctl list-units --type=service --state=running
把非系统自带的服务记下来：nginx、mysqld、php-fpm、docker、redis、frps，每个都是要搬的对象。
第二，Docker容器（如果有）：
docker ps -a
docker volume ls
第三，网站与数据的位置。常见位置心里过一遍：/var/www 或 /home/www（网站文件）、/etc/nginx（反代与站点配置）、/etc/letsencrypt（证书私钥）、/opt/selfhosted（自托管应用）、数据库的datadir。
第四，定时任务：crontab -l 逐条抄下来。这一项最容易被忘，搬完才发现备份任务、证书续期、日志清理全没了。
第五，杂项：SSH密钥对（~/.ssh）、自签证书、修改过的内核参数（sysctl）、ufw或iptables规则（ufw status）。
把这张清单写进一个文本文件，它就是整场搬家的施工图。强烈建议从第一台机器开始就维护这份文档，而不是搬家当天现盘。
二、新机器初始化：基础环境一步到位
新机器到手，别急着搬数据，先把地基打好。参照本站之前的新机安全加固教程做完基础项，这里只列与搬家直接相关的四步。
第一步，装齐同版本软件栈。老机器是Nginx+PHP+MySQL，新机器就装同样的组合。版本尽量对齐，尤其数据库：老机器MySQL 5.7、新机器装了8.0，导入时可能踩字符集和认证插件的变化。先查老版本：
nginx -v && php -v && mysql --version
第二步，建同样的目录结构和用户权限。目录对齐能省掉一半配置修改。
第三步，把老机器的SSH公钥、crontab先铺过去，方便后续操作。
第四步，临时打开大文件传输的通道：新机器上确保SSH可登录即可，rsync走SSH通道，不用额外开端口。
三、打包与传输：rsync才是主角
网站文件的迁移，核心工具是rsync。为什么不用tar打包再scp？三个原因：rsync支持断点续传，网络抖动不用重来；支持增量同步，第一次全量搬完后，切换前再跑一遍只传变化量，几秒结束；保留权限、属主、软链接，tar在异构系统解包时权限容易乱。
基本命令（在新机器上执行，从老机器拉取）：
rsync -avz --progress root@老机器IP:/var/www /var/www
参数解释：-a归档模式（保留权限、时间戳、软链）、-v显示过程、-z传输压缩、--progress显示进度。大文件多的时候-z能省不少时间。
逐项搬这些目录：
rsync -avz root@老IP:/etc/nginx /etc/ （站点与反代配置）
rsync -avz root@老IP:/etc/letsencrypt /etc/ （证书，含私钥）
rsync -avz root@老IP:/opt/selfhosted /opt/ （自托管应用数据）
两个细节。证书目录 letsencrypt 必须整目录搬，只拷live下的软链是不够的（真身在archive里）。Nginx配置搬过来后先 nginx -t 测试，涉及路径、上游地址的地方按新机器实际情况改。
这一步可以先做“预同步”：业务还在老机器跑的时候，先把大头的网站文件同步一遍。正式切换时再跑一次增量，把停机窗口压到最短。这是专业搬家的核心技巧：全量提前搬，增量停机搬。
四、数据库迁移：最容易翻车的环节
数据库是唯一必须停机处理的部件：写入进行中直接拷文件，大概率损坏。标准做法是 mysqldump 导出再导入，小库几秒，大库几分钟。
在老机器上导出：
mysqldump -u root -p --all-databases --single-transaction > /tmp/all.sql
--single-transaction 保证InnoDB导出的一致性快照，不锁表。如果只搬某几个库，把 --all-databases 换成库名列表。
传到新机器：
rsync -avz root@老IP:/tmp/all.sql /tmp/
在新机器导入：
mysql -u root -p < /tmp/all.sql
导入后三件验收事：SHOW DATABASES 核对库都在；抽查每个站的首页能否连库；核对MySQL用户和权限是否随dump一起过来了（--all-databases包含mysql库，用户通常自动带上，但host字段里如果写死了老机器内网IP，要UPDATE mysql.user改掉）。
Docker化的数据库同理：先 docker compose stop 停写入，再打包data目录，或者进容器执行mysqldump。
五、切换与验证：DNS不是点下去就完事
数据都到位后，进入切换环节。顺序很重要，按这个清单走：
1. 老机器上停掉写入源：把网站切维护模式，或停掉应用容器。此时开始计算停机时间。
2. 最后一轮增量rsync（网站文件）+ 数据库最终dump导入。
3. 新机器启动全部服务：systemctl start nginx 或 docker compose up -d。
4. 本机验证：curl -H 'Host:你的域名' http://127.0.0.1/ 检查每个站点、每个服务端口。
5. 改DNS解析：A记录从老IP指向新IP。TTL如果之前是3600，这次切换提前一天改成300，全球生效只要几分钟。
6. 等DNS生效期间，用手机流量（避开本机DNS缓存）访问验证。
一个高频坑：证书。certbot的续期定时任务在配置目录搬过来后通常直接可用，但有些机器上的续期后钩子里写死了reload命令路径，检查 systemctl list-timers 里的certbot项确认在新机器正常。
另一个坑：邮件。如果老机器上有发信任务（网站注册邮件），新机器IP的25端口信誉是全新的，可能进垃圾箱，这与搬家无关，属正常现象。
六、回滚预案：老机器别急着销户
DNS切换完成、验证通过，也别急着格式化老机器。标准做法：老机器保留至少7到14天，作为完整的热备回滚点。
保留期间做两件事。第一，老机器的Nginx配置改成只读镜像模式或直接停服务但保留数据，防止两边同时写入造成分叉。第二，DNS TTL保持300，万一发现新机器有隐藏问题（某个定时任务没搬、某个证书没续），随时把A记录指回老IP，五分钟内恢复。
彻底退役老机器前，最后过一遍第一节的资产清单：每项都确认在新机器上运转过至少一轮完整周期（比如一次每日备份任务、一次证书续期）。全绿，再去商家后台销户退款。
七、搬家检查清单（打印版）
搬前：资产清单盘点完成、新机器基础环境就绪、DNS TTL已降为300。
数据：全量rsync完成、数据库dump测试导入成功、证书目录完整迁移。
切换：老机停写、最终增量同步、新机服务全起、本机curl验证、DNS切换、移动网络验证。
搬后：老机器保留观察、定时任务逐项核对、一周后确认无异常再销户。
结语
搬家本质是工程问题，不是胆量问题。清单在手、增量同步、保留回滚，三招用足，换VPS就像换手机：数据完好、体验无缝、旧设备留作备份。会搬家之后，你对商家涨价、跑路、线路劣化的态度会完全不同——随时能走，才是用户最大的底气。
