网站迁移到搬瓦工教程：文件、数据库、DNS 切换和回滚
网站迁移最容易出错的地方，不是复制文件，而是切换期间仍在新增文章、订单和附件。只把昨天的备份恢复到新 VPS，再直接改 DNS，可能留下最近一天的数据缺口。
本文讲从另一台服务器迁移网站到搬瓦工，以 WordPress 为例。它和 KiwiVM 迁移机房 不同：新服务器需要自己部署环境、同步数据并切换域名。默认原域名保持不变；更换域名的处理另列。
一、先盘点源站环境
记录 PHP、数据库与 Web 服务版本、站点根目录、数据库名、附件目录、定时任务、后台队列、HTTPS 证书及第三方白名单。多站点、多租户或外部对象存储不能按单站假设复制。
确认业务允许的维护时间，以及谁能停止写入。电商、报名和评论密集的站点，不能只暂停首页访问，后台任务、支付回调和 API 也可能继续写入。
新 VPS 先完成系统、安全和数据库环境配置，参考 搬瓦工重装系统教程：Ubuntu / Debian 怎么选 与 搬瓦工 VPS 修改 root 密码、SSH 端口和 SSH Key 教程。用相同主版本建立测试环境，先验证兼容性，不在迁移当天顺便跨多个主版本升级。
二、第一次同步只做预复制
在新机器上使用有权限的账户，把源站文件拉到独立暂存目录。下面只给出占位端点，必须替换为已授权来源：
mkdir -p ~/migration/site
rsync -a --dry-run --itemize-changes \
-e 'ssh -p 22' \
[email protected]:/var/www/site/ ~/migration/site/
先审查预演列表，再去掉 --dry-run 执行第一次传输。源路径末尾的 / 表示复制该目录里的内容。不要直接加 --delete：它可能删除目标上已有但源端没有的文件，必须有独立计划和备份。[1]
源端账户应只有所需读取权限，先核对 SSH 主机指纹。目标暂存目录不应是已经服务公众的站点；Nginx/PHP 运行账号不同的机器，还要在部署时重新安排文件属主和权限，不能按用户名相同就假设 UID 一样。
三、导出数据库与准备新站
在旧服务器执行导出，输出保存到 Web 根目录以外的受限目录：
# 仅适用于使用本机 socket 管理 MariaDB 的示例环境
sudo install -d -m 0700 /root/site-migration
sudo sh -c 'umask 077; mariadb-dump --single-transaction \
--routines --events --triggers wp_site > /root/site-migration/wp_site.sql'
数据库名按实际修改。--single-transaction 适合事务表的一致性读取，不保证非事务表同样一致；导出期间也应避免改表结构。源库有其他引擎或业务写入要求时，先制定停写或专用备份方案。[2]
安全传输 SQL 到新服务器。新库应是专门建立的空库，名称和权限正确后再导入，绝不对着有生产数据的库尝试。本文示例使用相同数据库名减少差异，但用户密码应重新生成。
# 新服务器：确认 wp_site 是专用空库后才执行
sudo mariadb wp_site < /安全位置/wp_site.sql
重新填写 wp-config.php 的数据库信息，保留正确的表前缀和站点密钥。检查上传路径、缓存配置和定时任务，不要复制后立刻让新旧两边同时运行队列。
四、切换前先使用真实域名测试
# 新 IP 必须替换，域名使用真实站点域名
curl --resolve site.example.com:443:192.0.2.10 \
--connect-timeout 8 --max-time 30 -I https://site.example.com/
这保留 Host 和 TLS SNI，却临时连接新地址，不更改公开 DNS。需要浏览器操作时，可在管理电脑临时配置 hosts；测试结束后删去本地覆盖，避免以后仍误连旧地址。[3]
检查 HTTPS、登录、文章页、图片、插件任务和业务接口。带支付的站点先使用测试订单或受控测试流程，避免测试阶段产生无法对应的真实扣款。
同域名迁移通常不需要修改数据库中的站点地址。若确实换域名，不要直接对 SQL 文件做全文字符串替换，WordPress 的序列化数据需要专门处理。WP-CLI 可先预演：
# 在受控的新站副本中，以站点用户运行，不要直接对旧生产站执行
wp search-replace 'https://old.example.com' 'https://new.example.com' \
--all-tables-with-prefix --skip-columns=guid --dry-run
核对命中的表和字段、保存备份后，才去掉 --dry-run。多站点和插件自建表需额外确认；guid 不应当作普通 URL 字段随意替换。[4][5]
五、安排最终停写和增量同步
在维护窗口开始前提前降低 DNS TTL，并给原先较长 TTL 留出到期时间。降低 TTL 不会立即清除外部缓存，也不能保证所有访问同时切换。
窗口开始后，冻结旧站写入，暂停定时任务和队列，并安排好回调的重试或接收策略。再次同步最终文件，重新导出数据库并在新站导入，确认最新记录数量、时间和业务一致性。
旧站在缓存过渡期保持维护或只读，不再接收新数据；验证完毕后只开放新站写入。CDN 使用源站 IP 时还要更新回源地址，不能只修改普通 DNS 记录。IPv6、监控、PTR 和 IP 白名单也需要单独检查。
六、DNS 切换之后的观察
记录切换时间，使用不同网络验证解析和访问；看新站的访问日志、PHP 错误、数据库连接和后台任务。确保新站只有一份任务调度在工作，避免邮件、订单处理或同步任务执行两次。
保留旧实例和迁移备份一段观察期。具体时长按业务恢复需求决定，不承诺“等半小时就能删旧服务器”。不要提前取消续费或删除旧机器，尤其是新站还没有做过独立备份时。
七、回滚不只是把 DNS 改回去
切换后没有新写入时，回滚相对简单：停止新站、恢复旧入口并确认旧数据完整。若新站已经产生订单、评论或附件，必须先冻结写入并确定增量合并方法，不能用旧库覆盖新数据。
提前写好“回滚触发条件、决策人、数据源和具体步骤”，比临时讨论更有用。回滚测试应在副本上完成，不把生产站当作第一次演练环境。独立恢复方法可参考 搬瓦工快照与自动备份教程。
常见问题
只迁移网站文件够吗？
WordPress 的文章、用户和很多设置在数据库中，附件、主题和插件主要在文件中，两者都要保存。
可以让两个站同时开放写入吗？
除非已经设计了可靠的数据同步与冲突处理，否则不要。DNS 过渡期最容易造成分叉数据。
同一个域名迁移需要改所有链接吗？
通常不需要。先检查站点 URL 和路径，只在确实更换域名或协议时按受控方式处理。
相关阅读
参考资料
