Linux两个服务器之间发送文件夹，核心答案是：用rsync做增量同步，用scp做一次性拷贝，数据量小图省事就scp，数据量大、要断点续传或定期同步就rsync。这是几乎所有Linux运维都会给出的组合答案，两个命令都能把整个文件夹原封不动传过去，区别在于rsync更聪明，它会先对比两边文件差异，只传新增和改动的部分，scp则是无脑全量复制。
两个服务器传文件夹，先分清场景再选命令
很多人在简米云或酷番云上买了第二台服务器,想直接把原来机器上的网站目录搬过去，第一反应是压缩打包再下载上传，绕了一大圈，实际上Linux自带的远程传输命令就能直接搞定文件夹搬家，不需要中间环节，在动手之前，先明确你这是哪一种场景：
- 一次性搬家：新服务器刚买好，要把旧服务器的/home/wwwroot整个目录搬过去，搬完就不管了，这种情况直接scp最快，命令简单，不用记额外参数。
- 持续同步：两台服务器都在跑业务，要保证某个数据目录始终一致，比如负载均衡后面的两台Web服务器要同步图片附件，这种情况必须用rsync，它能定时增量同步，效率高很多。
- 跨国跨地域传输：服务器在不同机房，或者国内和香港、海外的机器互传，网络延迟高且不稳定，这时scp容易中断，rsync配合断点续传参数才是正确姿势，跑一半断了能从断点继续。
- 带宽有限的内网传输：机房内网机器之间传几百G的日志文件，先把目录打包成单个tar文件再传，比传几万个零散小文件快好几倍，这是两地服务器之间搬家时最容易被忽略的细节。
行业共识认为,scp适合临时应急操作，rsync适合需要长期维护的同步任务，如果你不确定选哪个，默认用rsync不会出错，它能覆盖scp的所有功能，还多了压缩、断点续传、增量同步这些关键能力。
linux服务器之间传输文件夹用什么命令？先学最简单的scp
scp全称是secure copy，基于SSH协议做加密传输，和密码登录服务器的机制一样，所以传输过程是加密的，不怕被中间人截获，用简米云服务器和酷番云服务器之间互传文件夹，操作路径如下。
从本机推送到远程服务器
登录到源服务器,执行：
scp -r /home/wwwroot root@192.168.1.100:/home/这条命令的含义：把本机/home/wwwroot整个目录复制到192.168.1.100这台服务器的/home目录下，登录用户是root。-r参数是关键，递归复制子目录
，不加它只能传单个文件。
执行后系统会提示输入远程服务器的root密码,输入正确就开始上传了，传完去远程服务器对应路径下ls检查一下，文件齐全就说明成功了。
从远程服务器拉取到本机
方向反过来,把命令的源和目的一对调：
scp -r root@192.168.1.100:/home/wwwroot /home/这会把远程服务器上的wwwroot文件夹拉到本机的/home目录下，日常运维中，从旧服务器拉数据到新服务器是最常见的操作路径，建议先在新服务器上执行拉取命令，这样数据流向是下载，带宽占用更可控。
用scp传大文件夹遇到中断怎么办
scp不支持断点续传,一旦网络抖动导致连接断开，传输失败，只能重新开始，几十G的目录传到一半断了，重来一遍相当痛苦，业内专家指出，遇到这种情况要么改用rsync，要么用tar打包加断点续传工具处理。
两台linux服务器间批量拷贝文件，rsync是进阶方案
rsync是Linux下最强的文件同步工具,它最大的价值是增量传输，第一遍全量传完后，后续再执行同样的命令，只传输两边有差异的文件，几百G的数据日常同步可能只需要传几MB的变动内容，这对服务器之间发送文件夹的效率提升是数量级的。
rsync最常用的一行命令
rsync -avzP --progress /home/wwwroot root@192.168.1.100:/home/拆解一下各参数的实际作用：
- -a：归档模式，保留文件权限、属主、时间戳等属性，传输完和原文件完全一致，不加这个参数可能导致网站程序文件权限错乱，访问报500错误。
- -v：显示详细传输过程，能看到正在传哪些文件。
- -z：传输时压缩，适合文本类文件，比如PHP、HTML、SQL文件能大幅减少传输量。
- -P：等于–partial和–progress的组合，支持断点续传，并显示传输进度，这是跨服务器传文件夹时最实用的参数组合。
执行后同样输入远程密码,rsync开始扫描对比文件差异，第一遍会完整传输整个目录，第二遍再执行时，你会发现速度极快，因为只处理有变化的文件。
两个服务器之间同步文件夹怎么处理密码问题
每次手动输入密码在定时同步场景下行不通,crontab定时任务无法交互输入密码，解决办法是配置SSH密钥登录，生成密钥对，把公钥放到目标服务器的authorized_keys里，免密登录后才能实现无人值守的自动同步，具体操作：
ssh-keygen -t rsa -b 4096
ssh-copy-id root@192.168.1.100执行完这两条,再次scp或rsync就不需要密码了，配置密钥后，crontab里写入同步脚本，两台服务器间的文件夹同步就能定时自动执行，这个操作比较常用于解决生产环境和备份服务器之间的数据一致性问题。
rsync删除远程多余文件保持两边完全一致
如果要求两台服务器的目录一模一样,源端删除的文件目标端也要删，需要加–delete参数：
rsync -avzP --delete /home/wwwroot root@192.168.1.100:/home/这个参数需要谨慎使用,它会让目标端严格跟随源端状态。方向搞反了会删除源服务器上的数据，执行前建议先在测试目录验证一次命令效果，或者先用–dry-run参数预演一遍。
跨服务器传大量小文件的三个实操方案对比
网站附件目录、图片素材库这类场景，文件动辄几十万个，数量多但每个都很小，直接scp -r或rsync传输这类目录，速度会非常慢，对比三个方案：
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| tar+ssh管道 | 一次性迁移大量小文件 | 打包后只传输单个文件流，效率最高 | 不支持断点续传，中断要重来 |
| rsync -z | 常规增量同步 | 断点续传，增量智能 | 大量小文件时效率不如打包传输 |
| 远程挂载+NFS | 两台服务器实时共享目录 | 无需手动传输，实时性最好 | 依赖网络稳定性，配置复杂度高 |
tar加ssh管道一条命令搞定
tar czf - /home/wwwroot | ssh root@192.168.1.100 "tar xzf - -C /home/"这条命令的原理是：在源服务器上把目录打包成tar.gz数据流，通过SSH管道直接传输到目标服务器，目标端解压到指定目录，整个过程不落地中间文件，不占用磁盘空间，传输效率是所有方案中最高的，行业共识认为，按文件数量衡量，打包传输比逐文件传输快数倍。
两台linux服务器间用FTP工具传文件夹
有些刚接触Linux的用户更习惯图形化操作,服务器之间发送文件夹也可以用SFTP工具，比如WinSCP、FileZilla，在本地电脑上打开WinSCP，新建两个站点分别连接两台服务器，然后直接从左侧拖拽到右侧窗口，这种方式适合零散文件传输，效率远不如命令行方案，大批量数据同步时性能差距明显。
传完之后怎么确认文件没丢没坏
文件传完后,直接看传输日志的返回信息是最基本的检查方式，更严谨的做法是逐一校验比对：
- 比文件数量：在两台服务器上分别执行
find /目录路径 -type f | wc -l，对比得到的总数是否一致。 - 比目录总大小：执行
du -sh /目录路径对比两边数据，大小差异超过合理范围说明有文件没传完整。 - 看rsync退出码：rsync执行后有回显状态，返回0表示正常完成，非0值代表有异常，需要用
echo $?查看具体退出码含义。
对于网站代码这类文本文件,传输完成后抽查几个文件的md5值，执行md5sum 文件名，两边对比hash值一致就没有问题，图片、压缩包等二进制文件可以抽查几个大文件确认完整性。
常见问题：linux服务器之间传输文件安全吗
加密层面不用担心,scp和rsync都走SSH加密通道，传输内容无法被网络抓包直接破解，实际操作中更需要关注的是权限问题，不要用root账号在公网上明文配置免密登录，建议创建一个专用同步账号，只授权需要同步的目录读写权限，简米云、酷番云的安全组规则里，也建议把SSH端口限制为只允许机房内网IP或堡垒机IP访问。
Q&A：linux两个服务器发送文件夹的常见问题
两台Linux服务器传文件夹一直提示权限拒绝怎么办
这是目标目录没有写入权限导致的,登录目标服务器，检查目标目录的属主和权限，用ls -ld /目标目录查看，确认当前登录用户是否有写权限，没有权限就执行chown -R 用户:用户组 /目标目录修改属主，或者选择其他有权限的目标路径。
rsync同步时目标端多出来的文件会被清掉吗
默认情况下不会,rsync只增量添加和更新文件，目标端多余的文件会原样保留，只有显式加了–delete参数才做删除对齐，如果你希望目标端完全镜像源端状态，可以加上这个参数，前提是确认源端数据准确无误。
服务器不在同一机房，传输速度很慢有什么加速方案
先测两端网络延迟和丢包,如果延迟过高，考虑改用rsync加-z压缩减少传输数据量，同时用-P断点续传兜底，大文件可以先在源端压缩打包再传输，小文件则建议先打包成tar文件传，能显著减少文件系统开销，如果延迟很高，也可以考虑用香港或海外的中转机器做跳板，绕过拥堵的国际链路。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/642053.html
