网站搬到新服务器后，首页能打开，上传图片却丢了一批；也有人把目录同步到错误位置，切换后才发现多套了一层文件夹。这类问题往往出在路径、同步范围和切换顺序上。
使用 rsync 迁移网站目录，可以先预演文件变化，再执行初次复制，最后在业务停止写入后补齐增量。目标目录应放在可独立验收的位置，确认配置和数据都可用之后再切流量。本文的命令是操作示例，没有在读者的服务器上实测；执行前需要替换主机、用户和路径。
确认网站目录之外还要迁移什么
本文适用于两台通过 SSH 连接的 Linux 服务器，示例把旧服务器 /srv/www/site/ 的内容复制到新服务器 deploy@new.example.net:/srv/www/staging/site/。命令在旧服务器运行，两端需要安装 rsync，SSH 用户要能读取源文件、写入目标目录。
文件迁移清单至少要覆盖程序代码、上传附件、配置文件，以及程序实际使用的外部存储。建议先记录站点根目录和上传目录，再检查软链接指向、挂载点与应用配置。上传文件放在独立磁盘或对象存储时，仅复制网站根目录可能无法覆盖全部数据。
数据库应另外准备一致性备份或迁移方案。正在运行的 MySQL 数据目录不能直接当作普通网站文件复制。MySQL 官方文档对逻辑备份、物理备份和在线备份有不同要求，应根据存储引擎和停机窗口选择方案。[2]
迁移前保留原服务器和已有备份，并记录 DNS、反向代理、数据库连接及上传路径的原值。迁移验收期间保留一条可以返回旧环境的路径。
把同步方向和目标路径写下来
示例命令从旧服务器推送到新服务器。先在新服务器创建专用的验收目录，让迁移账户获得必要的写入权限。这个目录是否适合直接成为正式站点目录，由实际部署方式决定。
先在旧服务器检查准备复制的目录：
ls -ld /srv/www/site/
du -sh /srv/www/site/
再检查新服务器的目标目录与所在文件系统：
ssh deploy@new.example.net \
'ls -ld /srv/www/staging/site/ && df -h /srv/www/staging/site/'
路径中应使用明确的站点名。不要把不确定的变量直接展开为源目录或目标目录，也不要把新服务器的正式站点目录拿来试命令。磁盘剩余容量要为文件复制和迁移期间的增长留出空间。
源路径结尾的斜杠需要特别注意。/srv/www/site/ 表示复制目录内的内容；省略这个斜杠时，rsync 会把源目录本身纳入目标路径，可能多出一层 site。[1] 路径是否正确，应以预演输出和目标目录实际层级为准。
先预演，再执行初次同步
在旧服务器执行：
rsync -an --itemize-changes \
-e 'ssh -p 22' \
/srv/www/site/ \
deploy@new.example.net:/srv/www/staging/site/
-n 是预演模式，不执行传输变化；--itemize-changes 展示准备处理的项目。[1] 核对源目录、目标主机和目录层级，并抽查上传附件、隐藏配置文件和软链接。
rsync 直接处理目录时会遍历其中的文件。示例保留 /srv/www/site/ 作为源路径，避免把路径改成依赖 shell 展开的 /srv/www/site/*；后者可能漏掉隐藏文件。[3] .env 等配置是否适合迁往新环境，需要逐项检查，其中的旧数据库地址、旧密钥或旧绝对路径可能仍需修改。
确认预演符合预期后，去掉 -n 执行初次同步：
rsync -a --itemize-changes \
-e 'ssh -p 22' \
/srv/www/site/ \
deploy@new.example.net:/srv/www/staging/site/
保存命令输出，检查退出状态。出现权限拒绝、磁盘满或读文件失败时，先定位对应文件，再判断是否需要补传。首轮复制期间旧站点仍可能写入，首轮完成后还需要安排最终同步。
示例没有加入 --delete。该参数会删除接收端同步范围内、发送端没有的文件。[1] 如果目标端存在独立日志、生成配置或其他站点资料，删除同步可能破坏它们。普通站点搬迁可以先完成不删除目标文件的复制，再单独评估镜像一致性的需求。确有需要时，也应先保留目标端可恢复备份，并用带有相同过滤规则的预演检查拟删除项目。
归档参数不能替代权限检查
-a 提供递归复制和常见文件属性保留，但不自动包含硬链接关系、ACL 和扩展属性；能否保存属主等属性还受接收端权限影响。[1] 普通迁移账户不一定能恢复旧服务器上的全部元数据。
验收时要对照新环境的运行用户，检查以下目录：
- 程序代码目录是否可读，是否需要限制写入。
- 上传、缓存和临时目录是否允许应用写入。
- 配置文件是否只对必要账户开放。
- 软链接的目标是否存在，并位于预期路径。
建议选取配置文件、一个历史附件和一个新建附件，分别核对权限与实际访问结果。需要调整属主或权限时，把修改范围限定在已经确认的目标目录。批量开放 777 会扩大写入权限，也无法解释原来的权限错误。
停止业务写入后再补最后一轮
首轮同步可以缩短最终切换时需要传输的文件量。正式切换前，应安排维护窗口，暂停旧站点上传、后台编辑和会修改文件的任务，并完成计划中的数据库迁移。
保持业务写入暂停，按相同方向和路径再执行一遍同步命令。随后核对数据库状态、上传目录和配置文件，再进入新环境验收。文件和数据库之间的业务关系需要一起检查，例如数据库中已经存在的附件记录，是否能在新站点找到对应文件。
如果切换后允许新站点写入，再把流量退回旧服务器，两个环境可能产生不同的新数据。回滚方案必须说明如何处理这段期间的订单、附件或编辑记录，不能只写“把 DNS 改回去”。对于需要持续写入的业务，应根据应用和数据库能力另行设计切换方案。
从文件检查走到业务验收
传输完成后，可以继续使用同一条预演命令检查是否仍有待处理差异。怀疑文件内容变化没有被正常识别时，可以在已经停止写入的目录上增加校验和比较：
rsync -acn --itemize-changes \
-e 'ssh -p 22' \
/srv/www/site/ \
deploy@new.example.net:/srv/www/staging/site/
-c 会通过内容校验和判断文件是否需要传输，读文件成本也随之增加；-n 保持预演。[1] 这项检查仍受当前同步范围和过滤规则约束，不能证明数据库、外部存储或未纳入目录的资源已经迁移。
文件检查之后，在新站点验证登录、历史图片、一次受控上传，以及业务关键页面。暂未切换 DNS 时，可以使用合适的测试域名，或者用 curl 将正式域名解析到新服务器测试。例如把下面的文档示例 IP 替换为新服务器公网 IP：
curl --resolve www.example.com:443:203.0.113.10 \
-I https://www.example.com/
--resolve 可以为指定的主机和端口提供临时地址。[4] 不建议给这项验收添加跳过证书验证的参数，否则 HTTPS 配置问题可能被遮住。请求能返回响应之后，还要检查页面内容、错误日志和上传结果。
记录同步命令、退出状态、数据库备份时间、验收项目和切换时刻。旧服务器与备份的保留期，应覆盖实际业务需要的观察窗口。这样再次发现缺失文件时，仍能定位来源并补齐。
官方参考资料
资料核验日期：2026 年 10 月 13 日。命令选项以服务器上安装版本的手册为准。