Ubuntu服务器之间互传文件夹：scp、rsync、NFS方案对比与rsync实战

1. 项目概述：别再拿U盘倒腾服务器文件了

做运维这几年，最让我头疼的事之一，就是两台Ubuntu服务器之间互相传文件。尤其是内网环境，没有外网网盘可用，FTP配起来麻烦，U盘拷贝在小文件时还能忍，一旦碰上几十GB的日志包、数据库备份或者深度学习模型权重，简直就是灾难。所以这个"Ubuntu服务器之间互传文件夹"的需求，虽然听起来基础，但背后牵扯到的问题一点都不少：传小文件用什么最快、传大目录怎么保证不断线、跨网段怎么处理、权限怎么保留、断点续传怎么实现……每一条都值得单独拎出来说。

这篇文章就围绕"两台Ubuntu服务器之间互传文件夹"这件事，把我实际用过、踩过坑、最后沉淀下来的方案全部摊开来讲。适合谁看？刚入行的运维新手、自己搭服务器玩的开源爱好者、以及被上司安排"把A机器目录同步到B机器"这种需求但不知道怎么下手的同学。文章不会只堆命令，我会把每个方案的适用场景、参数含义、为什么会这样选都讲清楚，确保你看完能直接照着抄。

先说明一下我写这篇文章的背景环境：两台服务器都是Ubuntu系统，一台是Ubuntu 20.04 LTS，一台是Ubuntu 22.04 LTS，均为内网IP直连，带宽千兆。如果你手头的环境是跨公网、高延迟、弱网，我在后面"常见问题"部分也会提到对应的调整思路。

2. 方案选型：scp、rsync、NFS还是其他

2.1 先理清楚你最常遇到的四种场景

在动手之前，我建议你先问自己一个问题：我到底是"传一次就行"，还是"以后要经常同步"？这两者的答案会直接决定你该选哪种工具。

我归纳下来，日常运维里"Ubuntu服务器之间互传文件夹"的需求基本跑不出这四种：

• 一次性传输：比如把打包好的代码、配置文件丢到另一台服务器，传完就结束，不需要后续维护。
• 定期同步：比如每天凌晨把A服务器的备份目录增量同步到B服务器，要求效率高、只传变化的部分。
• 实时挂载访问：比如把A服务器的大目录直接挂载到B服务器上，B服务器上的程序直接读写A服务器的文件，就像读取本地磁盘一样，这实际上是"共享文件夹"而非"一次性拷贝"。
• 异地容灾/迁移：比如整台服务器的/home或者/data目录要迁到新服务器，要求权限、软链接、硬链接等属性全部保留。

你会发现，scp、rsync、NFS这三种工具恰好分别对应前三种场景，而第四种场景通常是rsync配合特定参数来完成。剩下的问题就是，到底什么场景下选哪个，以及每种方案之间的边界在哪里。

2.2 scp：简单直接，但别把它当同步工具用

scp（Secure Copy）是我最早接触的方案。它的优势是语法足够简单，跟cp命令的使用习惯几乎一样，底层走的是SSH加密通道，不需要额外启动任何服务端守护进程。只要目标服务器的SSH服务是开着的、你有账号密码或密钥，就能直接传。

# 把本地目录整个拷到远程服务器 scp -r /data/backup user@192.168.1.101:/data/ # 从远程服务器把目录拷到本地 scp -r user@192.168.1.101:/data/backup /data/

但它的问题也很明显：不支持增量传输。每次都是全量拷一遍，文件越多越大，浪费的时间和带宽就越夸张。而且scp在传输大目录时一旦断线，就得从头再来，没有断点续传的能力。我在一次传30GB的模型文件时就吃过这个亏，传到一半网络抖动，scp直接报错退出，只能重新开始。

所以我的建议是：如果只是临时传几个文件、几十MB以内、网络稳定，scp完全够用；一旦涉及大目录、反复同步、跨弱网，直接跳过scp选rsync。

2.3 rsync：增量同步的王者，运维必会

rsync是我现在主力使用的方案。它不是简单地"把文件复制过去"，而是会先对比源目录和目标目录的差异，只传输变化的部分。首次全量传输之后，后续每次同步都只走增量数据，速度快到飞起，特别适合"定时备份"和"目录镜像"这种需求。

rsync本身有两种工作模式：一种是走SSH隧道（默认常用），另一种是走rsync daemon（需要额外配置rsync服务端）。对于"Ubuntu服务器之间互传文件夹"这种场景，强烈建议走SSH隧道模式，原因有三：第一，不需要在目标服务器常驻额外服务，只要SSH开着就行；第二，加密传输，数据在网络上不是明文流动的；第三，认证逻辑直接复用SSH的用户体系和密钥，管理成本最低。

# 基本用法：把本地目录同步到远程，-a是归档模式保留属性，-v显示过程 rsync -av /data/backup/ user@192.168.1.101:/data/backup/ # 注意源目录后面有没有斜杠，意思完全不同 rsync -av /data/backup user@192.168.1.101:/data/ rsync -av /data/backup/ user@192.168.1.101:/data/

这个斜杠的坑我后面会专门讲，先记住一句话：源目录带斜杠，拷贝的是目录内容；不带斜杠，拷贝的是目录本身。这种细节在rsync里非常容易翻车，尤其是你脚本化批量处理多个目录的时候。

2.4 NFS：让远程目录"变成"本地目录

NFS（Network File System）的思路跟scp、rsync完全不同。前两者是"把文件从A复制到B"，NFS是"把A的目录挂载到B，B上的程序直接读写A的文件"。换句话说，用NFS之后，你在B服务器上执行ls /mnt/shared，看到的其实是A服务器上的文件，整个过程不需要把文件实体拷贝到B服务器的磁盘里。

这种方案的适用场景是"共享"而不是"迁移"。比如你有两台Web服务器，图片资源统一放在存储服务器上，两台Web服务器都挂载同一份资源目录，就能保证内容一致，同时避免重复存储。NFS的缺点是它假设网络是可信的、低延迟的，默认配置下不适合跨公网使用，而且对网络抖动比scp/rsync敏感得多，NFS服务端一旦出问题，客户端可能会hang住。

如果你只是想把文件"传"过去，而不是"共享"着用，NFS就不太合适。但如果你需要的是多台机器实时访问同一份数据，NFS是Linux生态里最成熟、最直接的选择。

2.5 选型小结

我把三种方案的核心差异整理成一张表，方便你对着自己的需求选：

从这张表能看出，如果你不是特殊场景，绝大部分"互传文件夹"的需求都应该落在这句话上：小文件急用选scp，大目录/反复同步选rsync，多机实时共享选NFS。下面我重点讲rsync的完整实操，因为它覆盖面最广，也是我日常用得最多的。

3. rsync实操：从基础同步到高阶参数

3.1 首次使用前的基础准备

虽然rsync走的是SSH隧道，但它在传输过程中还是会调用本地的rsync程序。Ubuntu 20.04/22.04默认不一定装了rsync，尤其是最小化安装的服务器。所以第一步是两台机器都确认一下：

# 查看是否已安装 rsync --version # 如果提示找不到命令，就安装 sudo apt update && sudo apt install -y rsync

这一步说多了都是泪。我第一次在内网一台新装的Ubuntu服务器上跑rsync，本地执行命令正常，结果对端服务器一直报rsync: not found，排查了半天才发现是目标服务器根本没装rsync。它不是SSH通道里的内置功能，而是两端都要有rsync这个二进制文件。

接下来是SSH免密登录的配置。虽然rsync可以手动输入密码，但如果你是定时任务（crontab）里跑同步，就必须配置密钥免密登录。具体做法：

# 在源服务器上生成密钥（如果还没生成过） ssh-keygen -t ed25519 -C "rsync-sync" -f ~/.ssh/id_ed25519 # 把公钥拷贝到目标服务器 ssh-copy-id user@192.168.1.101 # 验证免密是否成功 ssh user@192.168.1.101 "hostname"

生成密钥时我推荐用ed25519算法，比传统的RSA密钥更短、更安全，而且OpenSSH 7.0以上都支持，Ubuntu 20.04/22.04完全没问题。如果某些老系统不支持，再退回RSA 4096位。

3.2 最常用的同步命令与参数详解

基础的同步命令大家都见过，网上随便一搜就是rsync -av，但很多教程没有告诉你每个参数到底在干什么，导致实际出问题时不知道怎么调整。我这里把我最常用的一套参数拆开讲：

rsync -avz --progress --partial --delete /data/backup/ user@192.168.1.101:/data/backup/

逐个说：

• -a：归档模式。等价于-rlptgoD，意思是递归同步、保留软链接、保留权限、保留时间戳、保留属组、保留所有者、保留设备文件。在做迁移类操作时，这个参数异常重要。比如你用cp -r拷贝Java应用目录，经常会出现因为文件属主变了导致程序起不来的情况，rsync加-a就不会有这个问题。
• -v：verbose，输出同步过程的详细信息，方便观察哪些文件被传输了。
• -z：传输时启用压缩。内网千兆带宽下其实压缩收益不大，甚至可能因为CPU开销拖慢速度，但跨公网、小文件多的场景压缩效果明显。我的习惯是，内网大文件不加-z，跨小水管加-z。
• --progress：显示每个文件的传输进度，尤其是传大文件时，你能看到实时速度，心理上也有底。
• --partial：保留部分传输的文件。这个参数一定要加，因为rsync默认在传输中断时会删除目标端不完整的临时文件，加了这个参数后，下次再传同一个文件，会基于已有的部分数据续传，等于变相实现了断点续传。
• --delete：删除目标端多余的文件，让目标目录跟源目录完全一致。注意，这个参数有危险，如果源目录路径写错，目标端可能被清空，后面我会讲怎么避免。

我实测过一组数据：在千兆内网中，用rsync -avz同步一个包含10万个小文件的目录（总大小8GB），首次全量大概需要12分钟；第二次改动其中100个文件再同步，耗时不到10秒，因为只传输了变化的部分。这个效率差异正是rsync的核心价值所在。

3.3 斜杠陷阱：源路径末尾的/到底加不加

这是一个非常经典的rsync翻车点。同样是/data/backup，末尾加不加斜杠，同步结果完全不同：

# 不带斜杠：把backup这个目录本身同步过去 # 结果是 目标:/data/backup 目录变成了源backup目录的副本 rsync -av /data/backup user@192.168.1.101:/data/ # 带斜杠：把backup目录里的内容同步过去 # 结果是 目标:/data/backup/ 里的内容与源backup目录里的内容一致 rsync -av /data/backup/ user@192.168.1.101:/data/backup/

换个更直白的说法：源路径末尾带斜杠，表示"我要同步这个目录里面的东西"；不带斜杠，表示"我要同步这个目录本身"。实际应用中，我见过有人没注意这个细节，结果在目标服务器上多了一层嵌套目录，比如本来想同步到/data/backup，最后生成了/data/backup/backup。排查这种问题不算难，但浪费的时间足够让人抓狂。

我的经验是，在写crontab定时同步脚本时，统一使用带斜杠的源路径，并且目标路径也明确指向具体的目录名，这样语义最清晰，不容易出错。

3.4 删除保护：避免--delete误删数据的血泪教训

--delete参数是把双刃剑。配合-a使用后，同步语义就从"往目标目录里添加/更新文件"升级为"让目标目录完全镜像源目录"。这意味着，如果源目录因为某种原因空了或者路径写错了，rsync会让目标目录也变空，后果极其严重。

我个人的防护习惯有三条，分享给你参考：

第一，永远不要把源路径写成/这种根路径。哪怕你觉得"我就同步根目录下某个子集"，也别这么干，因为稍有不慎就是灾难级别的事故。

第二，先做一次--dry-run演练。rsync提供了-n参数，也叫dry-run模式，它只计算差异、不实际执行传输和删除。执行完看一遍输出，确认要删除的文件确实是你预期中的那些，再真正跑同步：

rsync -avn --delete /data/backup/ user@192.168.1.101:/data/backup/

注意，-n通常配合-v一起用，因为只有输出详细信息你才能看到它打算干什么。这一步多花十秒，能避免很多不可逆的后果。

第三，目标端保留一份带日期的历史快照。做法是先把当前目标目录重命名成带时间戳的备份，再执行同步，相当于给每次同步前留了一条退路：

# 在目标服务器上提前执行 mv /data/backup /data/backup_$(date +%Y%m%d_%H%M%S)

然后源端再执行rsync，让/data/backup目录从零开始被镜像。这样即使同步过程中出现意外，你还能从快照目录里把原文件捞回来。这个习惯在运维里价值极高，我后来甚至把类似思路写进了备份脚本里。

3.5 断点续传与弱网优化

前面提到，--partial可以让rsync基于已传输的部分数据续传，但要想真正实现"断线后重新执行命令即可续传"，通常还需要配合--append或--append-verify参数。

• --append：追加模式，如果目标已有文件比源文件短，只追加差异的部分。这个参数适合日志文件这类只增不改的文件。
• --append-verify：追加后再比对校验，多一次验证，代价是速度略慢。

对于跨公网传输大文件，我常用的命令是这样的：

rsync -avz --partial --append-verify --timeout=60 /data/bigfile.iso user@192.168.1.101:/data/

--timeout=60表示如果60秒内没有数据传输，就判定连接超时退出，避免连接假死导致rsync进程一直挂着，占着带宽和CPU。

弱网环境下还有几个实用参数：--bwlimit可以限制传输带宽，比如--bwlimit=2000表示限速2MB/s左右。为什么要限速？因为如果同步任务占了全部上行带宽，可能会影响服务器上正在运行的其他业务，尤其是数据库同步之类对延迟敏感的服务。在生产服务器上跑大批量同步之前，先限速观察一下，是个好习惯。

4. 进阶玩法：定时同步、排除规则与NFS补充

4.1 用crontab实现无人值守的定时同步

当rsync命令在你手动执行下已经没有问题时，下一步就是把它写进crontab，实现每天/每小时自动同步。我的推荐做法不是直接写一行很长的rsync命令到crontab里，而是先写成一个独立脚本，方便维护和日志记录。

#!/bin/bash # /usr/local/bin/sync_backup.sh source_ip="192.168.1.100" source_dir="/data/backup/" target_ip="192.168.1.101" target_dir="/data/backup/" target_user="syncuser" rsync -avz --partial --delete \ -e "ssh -i /home/syncuser/.ssh/id_ed25519" \ ${source_dir} ${target_user}@${target_ip}:${target_dir} \ >> /var/log/rsync_backup.log 2>&1

注意这里用了-e "ssh -i ..."指定SSH私钥路径。如果你是用root用户跑crontab，而rsync的目标认证用户是普通用户，就必须明确指定用哪个私钥去连接，否则可能因为/root/.ssh下没有对应密钥而登录失败。

然后编辑crontab：

crontab -e # 每天凌晨2点执行同步 0 2 * * * /bin/bash /usr/local/bin/sync_backup.sh

这里有几个细节值得关注：脚本里重定向了标准输出和错误输出到日志文件，方便事后排查；crontab中建议写绝对路径/bin/bash，因为定时任务的环境变量跟交互式shell不同，直接写bash可能因为PATH问题找不到解释器。我踩过这个坑之后，所有crontab里涉及的命令一律写绝对路径。

4.2 排除不需要同步的目录

实际环境中，一个应用目录里往往不是所有内容都需要同步。比如Java应用目录下面有logs/和temp/，日志天天变但没必要天天备份，临时文件更是可有可无。rsync提供了--exclude参数：

rsync -avz --delete \ --exclude='logs/' \ --exclude='temp/' \ --exclude='*.cache' \ /app/ user@192.168.1.101:/app/

如果你有多个排除项，也可以把它们统一写进一个文件里，用--exclude-from指定：

# exclude.list 内容示例 logs/ temp/ *.tmp *.cache .git/

rsync -avz --delete --exclude-from=/etc/rsync_exclude.list /app/ user@192.168.1.101:/app/

用排除文件的优势是，新增排除规则时不用改脚本本身，只要编辑文本文件即可。配合--delete一起用时要特别小心：--delete和--exclude组合时，被排除的内容不会被删除，这一点rsync处理得很好，不用担心目标端因为排除规则而丢掉原本想保留的目录。

4.3 公网环境下的SSH端口与安全加固

默认SSH端口是22，但如果你通过公网传输文件，把SSH端口暴露在公网上就等于每天被各种扫描器试探。最稳妥的做法是修改SSH端口，或者用防火墙限定来源IP。rsync的-e参数可以指定SSH连接端口：

rsync -avz -e "ssh -p 2222 -i /home/syncuser/.ssh/id_ed25519" \ /data/backup/ user@server.example.com:/data/backup/

安全方面除了改端口，还有两件事值得做：一是禁用root密码登录，改用密钥认证；二是在/etc/ssh/sshd_config里确认PasswordAuthentication no。这些属于SSH基础加固，但对公网环境下的文件同步来说，属于保命操作。

4.4 NFS配置速查：Ubuntu 20.04/22.04通用

如果你最终确定需要的是"NFS共享"而不是"文件拷贝"，配置过程也不复杂。NFS服务端（提供共享目录的机器）：

# 安装NFS服务端 sudo apt update && sudo apt install -y nfs-kernel-server # 编辑/etc/exports，添加共享目录规则 echo "/data/shared 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)" | sudo tee -a /etc/exports # 导出并重启NFS服务 sudo exportfs -ra sudo systemctl restart nfs-server

NFS客户端（挂载共享目录的机器）：

# 安装NFS客户端 sudo apt update && sudo apt install -y nfs-common # 创建挂载点并挂载 sudo mkdir -p /mnt/shared sudo mount -t nfs 192.168.1.100:/data/shared /mnt/shared # 设置开机自动挂载，需要写/etc/fstab echo "192.168.1.100:/data/shared /mnt/shared nfs defaults,_netdev 0 0" | sudo tee -a /etc/fstab

配置/etc/exports时，rw表示读写，sync表示数据同步写入磁盘，no_subtree_check减少检查开销，no_root_squash允许客户端root用户按root权限操作文件。其中no_root_squash比较危险，建议只在完全信任的内网环境使用，否则客户端root可以以root身份读写共享目录，安全风险较高。

我实际用NFS的场景是两台Web服务器共享同一份静态资源目录。之前图片各存各的，导致两台服务器上同样的URL访问结果不一致；后来改成NFS挂载共享目录，彻底解决了数据一致性问题。但需要注意，NFS对网络延迟敏感，如果你的内网交换设备有问题，NFS访问会变得很卡，甚至出现挂载点hang死的现象。遇到这种情况，优先检查网络抓包和网卡丢包率。

5. 常见问题与排查技巧实录

5.1 rsync报错"Permission denied"怎么办

这个报错可能是两类原因：一是SSH登录失败，二是目标目录没有写权限。区分方法很简单，先单独执行一下SSH登录：

ssh user@192.168.1.101

如果这一步都登录不了，说明问题在认证环节，检查账号、密钥权限、sshd_config配置。如果SSH能登录但rsync仍然报Permission denied，那就是目标目录的权限问题，去目标服务器上看一下目录属主和权限位：

ls -ld /data/backup sudo chown -R user:group /data/backup

我遇到过一个比较隐蔽的情况：目标目录权限没问题，但用户SSH登录后被分配到了一个受限shell（比如/usr/sbin/nologin），导致rsync无法执行。排查时要看/etc/passwd里该用户的shell字段，以及~/.ssh/authorized_keys里是否限制了command。

5.2 传输到一半中断，文件不完整

典型症状是：rsync执行到某个大文件时网络断开，目标端留下一个不完整文件，下次同步时rsync认为目标已有同名文件，可能直接跳过。解决办法就是我前面提过的--partial和--append-verify组合。另外，如果文件校验失败（比如源文件在传输过程中被写），rsync会报file has vanished或者校验错误，这种时候建议先暂停写入源目录的进程，再做一次全量同步。

还有一种常见情况是网络设备（防火墙/交换机）主动断开长连接。此时可以给SSH层加ServerAliveInterval和ServerAliveCountMax参数：

rsync -avz -e "ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=2" \ /data/backup/ user@192.168.1.101:/data/backup/

ServerAliveInterval=30表示每30秒向服务器发送一个保活包，避免连接因为长时间无流量被中间设备判定为超时而切断。传输小文件不成问题，但传海量小文件时SSH隧道长时间有数据、但单个包很小，有时候仍会被奇怪的中间设备误杀，这个参数能有效缓解。

5.3 同步后目标目录权限变了

rsync的-a参数会保留源文件的权限和属主，但前提是目标服务器上有对应的用户和组存在。如果你在源服务器上文件的属主UID是1005，而目标服务器上没有UID为1005的用户，rsync会直接以该数字UID写入文件元数据，你从目标服务器上ls -l看到的会是数字而不是用户名。

处理方式有两种：一是确保两台服务器使用统一的账号体系（比如都通过LDAP/FreeIPA管理用户）；二是同步后手动执行chown -R调整属主。如果只是临时迁移，我更推荐第二种，但要注意调整属主时别把原本该保留的system用户文件弄乱。

5.4 传输速度很慢，怎么排查

先确认瓶颈在哪。最简单的做法是，先跑一次纯SSH登录测试，再用iperf3测带宽，最后再看rsync参数。如果iperf3测出带宽本身就有问题，那工具怎么优化都没用，得先修网络。如果带宽正常但rsync很慢，大概率是小文件太多，这时候考虑--compress-level调低压缩级别，或者干脆取消压缩（内网场景）。另一个隐藏瓶颈是磁盘IO：大量小文件时，源端读盘和目标端写盘都可能成为瓶颈，可以用iotop观察。

我遇到最极端的一次，是rsync同步10万个文件，全程不到100MB，但跑了40多分钟。后来排查发现，目标服务器的磁盘是机械盘，而且同时还有其他任务在大量写入。后来把同步时间调整到业务低峰期，同样一批文件只用了不到10分钟。

5.5 快速排查清单

6. 写在最后：一点个人体会

回到开头那句话：Ubuntu服务器之间互传文件夹，看起来是个再基础不过的需求，但真正把它做好，涉及的细节一点都不少。我在实际使用中最深的体会是，工具本身不难，难的是理解每个参数背后的语义，以及在不同网络条件下做对的取舍。rsync的--delete、--partial、-a这些参数，单独看都是几秒钟能记住的选项，但组合到一起，就是在"高效同步"、"安全防护"和"异常恢复"三者之间找平衡。

如果你手头的场景就是普通的内网两台服务器传目录，我建议直接把rsync配合SSH密钥的方案搭起来，再用crontab做定时同步，这套组合足够覆盖90%以上的需求。如果你是要迁移整台服务器，记得先用-avn --delete做一次dry-run，确认差异后再正式执行，这个习惯能救你很多次。最后再分享一个小技巧：在同步脚本里加一行echo "$(date '+%Y-%m-%d %H:%M:%S') sync finished"写入日志，光凭这个时间戳，你排查历史同步问题时就能少掉不少头发。