网络差，SSH 传的太慢，使用 USB 移动硬盘实现高速数据迁移（笔记）

m0_73177436

26人浏览 · 2026-11-06 11:59:01

m0_73177436 · 2026-11-06 11:59:01 发布

1. 背景：SSH 传输 4 GB 数据竟然需要 6 小时

8. 第五步：使用 tmux 防止 SSH 中断

9. 第六步：使用 rsync 将服务器文件复制到 USB

11. 第八步：安全卸载 USB 移动硬盘

12. 第九步：将数据复制到本地 Ubuntu

13. 实验结果：SSH 与 USB 传输对比

14. 常见问题

Q1：为什么服务器能通过 SSH 操作 USB 硬盘？

Q2：为什么复制4 GB的数据只需要几秒？

Q3：为什么 ls 显示68K？

Q4：SSH 意外断开，USB 复制会停止吗？

1. 背景：SSH 传输 4 GB 数据竟然需要 6 小时

在进行机器人强化学习实验时，需要经常将服务器上的训练日志、模型权重以及实验结果下载到本地 Ubuntu 工作站，用于模型评估、数据分析和实验对比。

通常采用 rsync + SSH 的方式进行远程文件同步：

rsync -avh --partial --progress \
  train-server:/home/humming/xuweiwork/Uni-SuperMimic/runs/... \
  /home/xuwei/Desktop/xuexi/Uni-SuperMimic/runs/

这种方法操作简单，并且支持断点续传。

但在实际使用中，发现服务器与本地电脑之间的网络连接非常慢。

本次需要传输的 Uni-SuperMimic 训练结果共约 4 GB，使用 SSH 传输时，预计需要约 6 小时。

因此，尝试使用另一种方式：

直接将 USB 移动硬盘连接到服务器，通过 SSH 操作服务器，将文件从服务器 SSD 复制到 USB 移动硬盘，然后把移动硬盘拿到本地电脑读取。

本次实际操作中，USB 复制命令约 5 秒便结束，明显快于原来的 SSH 网络传输流程。

不过，复制命令结束不代表数据一定已经全部写入物理硬盘，还需要检查实际传输量、校验数据并完成安全卸载。

2. 整体方案

传统的 SSH 文件传输：

┌──────────────────────┐
│  服务器 Ubuntu        │
│                      │
│  Uni-SuperMimic      │
│  训练数据 4 GB        │
└──────────┬───────────┘
           │
           │ SSH / rsync
           │
           │ 网络传输速度较慢
           │
           ▼
┌──────────────────────┐
│  本地 Ubuntu 工作站   │
│                      │
│  amp_walk_run        │
│  Uni-SuperMimic      │
└──────────────────────┘

实际观察：
约 4 GB → 6 小时

改进后的 USB 传输：

┌──────────────────────┐
│  服务器 Ubuntu        │
│                      │
│  服务器 SSD           │
│  Uni-SuperMimic      │
└──────────┬───────────┘
           │
           │ USB 本地文件复制
           │
           ▼
┌──────────────────────┐
│  WD My Passport      │
│                      │
│  USB 移动硬盘         │
│  NTFS 文件系统        │
└──────────┬───────────┘
           │
           │ 拔下移动硬盘
           │ 连接本地电脑
           ▼
┌──────────────────────┐
│  本地 Ubuntu 工作站   │
│                      │
│  复制实验数据         │
└──────────────────────┘

实际观察：
约 4 GB 数据集对应的复制命令约 5 秒结束

该方案的优点是文件内容不再经过服务器和本地电脑之间的网络传输。

SSH 只用于远程控制服务器。

适用场景： 服务器网络速度慢、需要搬运大量实验数据、能够直接接触服务器硬件，并且有足够容量的移动硬盘。

3. 实验环境

本次实际使用的设备信息如下：

项目	实际配置
服务器	train-server
服务器主机名	mscape-MS-7E13
服务器用户名	humming
服务器系统	Ubuntu
项目名称	Uni-SuperMimic
移动硬盘	WD My Passport
硬盘容量	1.8 TB
文件系统	NTFS
移动硬盘设备	`/dev/sda1`
服务器挂载路径	`/mnt/transfer_usb`
实验数据大小	约 4.0 GB
目标实验数量	17 组
主要工具	SSH、lsblk、mount、rsync、tmux

本次实验数据所在目录：

/home/humming/xuweiwork/Uni-SuperMimic/runs/V1_server1_gpu0_20261105_151414

包含：

V1_C0
V1_F01 ~ V1_F11
V1_T01 ~ V1_T05

共 17 组实验。

4. 第一步：SSH 登录服务器

在本地 Ubuntu 打开终端：

ssh train-server

成功登录后：

(base) humming@mscape-MS-7E13:~$

后续命令都在服务器 SSH 终端中执行。

需要注意，虽然通过 SSH 登录服务器，但后面的文件复制是在服务器本地磁盘和 USB 硬盘之间完成的。

因此不再受到 SSH 文件传输速度的限制。

5. 第二步：插入 USB 移动硬盘

将 WD My Passport 移动硬盘插入服务器的 USB 接口。

然后执行：

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS,TRAN

本次实际输出中的关键信息为：

NAME          SIZE FSTYPE   LABEL       MOUNTPOINTS  TRAN

sda           1.8T                                  usb
└─sda1        1.8T ntfs     My Passport

nvme0n1       1.8T                                  nvme
├─nvme0n1p1     1G vfat                 /boot/efi
└─nvme0n1p2   1.8T ext4                 /

从中可以确定：

设备	说明
`/dev/sda`	USB 移动硬盘
`/dev/sda1`	USB 硬盘的数据分区
`/dev/nvme0n1`	服务器内部系统盘
`My Passport`	移动硬盘名称
`ntfs`	移动硬盘文件系统

由于 /dev/sda1 的 MOUNTPOINTS 为空，说明硬盘虽然已经被识别，但是还没有挂载。

注意：每次插入移动硬盘，都需要重新确认设备名称。不能默认移动硬盘一定是 /dev/sda1，避免误操作服务器系统盘。

6. 第三步：挂载 USB 移动硬盘

Linux 中需要先挂载硬盘，才能通过文件路径访问其中的数据。

6.1 创建挂载目录

sudo mkdir -p /mnt/transfer_usb

本次执行结果：

(base) humming@mscape-MS-7E13:~$ sudo mkdir -p /mnt/transfer_usb
[sudo] humming 的密码：
(base) humming@mscape-MS-7E13:~$

没有报错，说明目录创建成功。

6.2 挂载 NTFS 硬盘

执行：

sudo mount -t ntfs3 \
  -o uid=$(id -u),gid=$(id -g) \
  /dev/sda1 /mnt/transfer_usb

参数说明：

参数	作用
`mount`	挂载文件系统
`-t ntfs3`	使用 Linux 的 NTFS3 驱动
`uid=$(id -u)`	将文件访问权限映射到当前用户
`gid=$(id -g)`	设置用户组
`/dev/sda1`	移动硬盘分区
`/mnt/transfer_usb`	挂载目标目录

本次执行后没有报错，说明挂载成功。

如果当前系统不支持 ntfs3，可以检查是否安装 ntfs-3g 并使用对应驱动。

如果出现文件系统损坏、Windows 休眠等错误，不应强制读写挂载，应先检查硬盘状态。

6.3 检查硬盘挂载情况

执行：

df -h /mnt/transfer_usb

实际结果：

文件系统        大小  已用  可用 已用% 挂载点

/dev/sda1       1.9T  1.2T  670G   65% /mnt/transfer_usb

说明：

移动硬盘挂载成功。
总容量约 1.9 TB。
已经使用约 1.2 TB。
剩余约 670 GB。

当前容量足够保存本次 4 GB 的实验数据。

6.4 测试是否具有写入权限

执行：

touch /mnt/transfer_usb/.write_test && \
rm /mnt/transfer_usb/.write_test

这条命令会在移动硬盘上创建一个测试文件，然后删除它。

本次执行后没有报错，说明可以正常写入。

7. 第四步：检查需要复制的数据大小

设置服务器源目录：

SRC=/home/humming/xuweiwork/Uni-SuperMimic/runs/V1_server1_gpu0_20261105_151414

检查17组实验的大小：

du -sch \
  "$SRC"/V1_C0 \
  "$SRC"/V1_F{01..11} \
  "$SRC"/V1_T{01..05}

本次实际结果：

237M    V1_C0
237M    V1_F01
237M    V1_F02
237M    V1_F03
237M    V1_F04
237M    V1_F05
237M    V1_F06
237M    V1_F07
237M    V1_F08
237M    V1_F09
237M    V1_F10
237M    V1_F11
237M    V1_T01
237M    V1_T02
237M    V1_T03
237M    V1_T04
237M    V1_T05

4.0G    总计

这说明17组实验的总磁盘占用约为4 GB。

注意：du 显示的是磁盘占用量，而不是严格的文件字节数。由于服务器使用 ext4、移动硬盘使用 NTFS，两边的磁盘占用量可能略有差异。

8. 第五步：使用 tmux 防止 SSH 中断

如果传输过程中 SSH 意外断开，前台运行的复制命令可能被终止。

因此建议使用 tmux 保持后台任务运行。

8.1 创建 tmux 会话

tmux new -s usb_copy

进入新的 tmux 终端。

8.2 暂时退出 tmux

按：

Ctrl + B
然后按 D

这样会返回普通 SSH 终端，但 tmux 内的任务继续运行。

8.3 重新进入 tmux

tmux attach -t usb_copy

8.4 查看 tmux 会话

tmux ls

8.5 彻底退出 tmux

确认复制任务完成后，在 tmux 中执行：

exit

如果出现：

[exited]

说明 tmux 会话或窗口已经结束。

9. 第六步：使用 rsync 将服务器文件复制到 USB

这是整个操作中最关键的一步。

由于已经通过 SSH 登录服务器，所以执行的是本地文件复制。

SRC=/home/humming/xuweiwork/Uni-SuperMimic/runs/V1_server1_gpu0_20261105_151414

DST=/mnt/transfer_usb/V1_server1_gpu0_20261105_151414

9.2 创建目标文件夹

mkdir -p "$DST"

9.3 复制17组实验

rsync -rtvh --partial --info=progress2 --stats \
  "$SRC"/V1_C0 \
  "$SRC"/V1_F{01..11} \
  "$SRC"/V1_T{01..05} \
  "$DST"/

其中：

参数	功能
`-r`	递归复制文件夹
`-t`	保留文件修改时间
`-v`	显示复制过程
`-h`	以 KB、MB、GB 显示文件大小
`--partial`	保留未传输完成的部分文件
`--info=progress2`	显示总体复制进度
`--stats`	输出实际传输量和统计信息

这里特别推荐添加 --stats。

因为它可以帮助判断：

本次究竟真正传输了多少数据，还是 rsync 跳过了已经存在的文件。

例如，传输结束后可以重点查看：

Total file size
Total transferred file size
Literal data

如果 Total transferred file size 接近4 GB，说明本次确实处理了大量需要传输的文件。

如果接近0，则说明大部分文件已存在，没有重新传输。

9.4 复制后的目录结构

/mnt/transfer_usb/
│
└── V1_server1_gpu0_20261105_151414/
    ├── V1_C0/
    ├── V1_F01/
    ├── V1_F02/
    ├── V1_F03/
    ├── V1_F04/
    ├── V1_F05/
    ├── V1_F06/
    ├── V1_F07/
    ├── V1_F08/
    ├── V1_F09/
    ├── V1_F10/
    ├── V1_F11/
    ├── V1_T01/
    ├── V1_T02/
    ├── V1_T03/
    ├── V1_T04/
    └── V1_T05/

10. 第七步：检查移动硬盘中的数据

10.1 查看实验文件夹

执行：

ls -lh /mnt/transfer_usb/V1_server1_gpu0_20261105_151414/

本次实际结果：

总计 68K

V1_C0
V1_F01
V1_F02
V1_F03
V1_F04
V1_F05
V1_F06
V1_F07
V1_F08
V1_F09
V1_F10
V1_F11
V1_T01
V1_T02
V1_T03
V1_T04
V1_T05

共17个目录。

这里有一个容易误解的问题：

为什么明明复制了4 GB的数据，ls -lh 却显示只有68K？

原因是 ls -lh 显示的是当前目录中的目录项和文件信息，不会递归统计每个子目录内的全部文件。

因此，68K并不代表只复制了68 KB。

10.2 查看移动硬盘中实际数据大小

执行：

du -sh /mnt/transfer_usb/V1_server1_gpu0_20261105_151414/

如果输出约4 GB，说明目标目录中确实保存了约4 GB的数据。

但这仍不足以证明每个文件都完整。

10.3 对比原始数据与目标数据

SRC=/home/humming/xuweiwork/Uni-SuperMimic/runs/V1_server1_gpu0_20261105_151414

DST=/mnt/transfer_usb/V1_server1_gpu0_20261105_151414

echo "===== 服务器数据大小 ====="

du -sch "$SRC"/V1_C0 "$SRC"/V1_F{01..11} "$SRC"/V1_T{01..05}

echo "===== USB数据大小 ====="

du -sch "$DST"/V1_C0 "$DST"/V1_F{01..11} "$DST"/V1_T{01..05}

两边数据大小应该大体接近。

10.4 使用校验和验证数据完整性

对于重要的训练模型，推荐执行：

rsync -rtvcn --itemize-changes \
  "$SRC"/V1_C0 \
  "$SRC"/V1_F{01..11} \
  "$SRC"/V1_T{01..05} \
  "$DST"/

参数解释：

-c：按文件内容计算校验和。
-n：仅检查，不实际复制。
--itemize-changes：显示存在差异的文件。

如果命令正常完成，没有出现需要重新传输的文件，说明这些文件的内容校验通过。

注意：校验过程中会读取全部数据，可能需要一定时间。如果训练任务仍在修改日志，建议在文件停止变化后再执行最终校验。

11. 第八步：安全卸载 USB 移动硬盘

这一步不能省略。

即使 rsync 已经执行完成，Linux 仍可能存在尚未写入物理硬盘的数据缓存。

因此执行：

sync

等待命令结束，确保缓存数据完成同步。

然后：

sudo umount /mnt/transfer_usb

检查是否卸载成功：

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS,TRAN

正常应该看到：

sda       1.8T                         usb
└─sda1    1.8T ntfs My Passport

此时 /dev/sda1 的挂载位置为空。

确认卸载成功后，再拔下移动硬盘。

12. 第九步：将数据复制到本地 Ubuntu

将 My Passport 连接到本地电脑。

查看实际挂载位置：

lsblk -f

假设移动硬盘自动挂载在：

/media/xuwei/My Passport

需要将数据复制到：

/home/xuwei/Desktop/xuexi/Uni-SuperMimic/runs/V1_local_20261105_121904/

创建本地目标目录：

mkdir -p /home/xuwei/Desktop/xuexi/Uni-SuperMimic/runs/V1_local_20261105_121904

执行复制：

rsync -rtvh --partial --info=progress2 --stats \
  "/media/xuwei/My Passport/V1_server1_gpu0_20261105_151414/" \
  /home/xuwei/Desktop/xuexi/Uni-SuperMimic/runs/V1_local_20261105_121904/

注意，源目录最后的 / 表示复制目录中的内容，而不是把整个目录再嵌套一层。

因此本地结果为：

V1_local_20261105_121904/
├── V1_C0/
├── V1_F01/
├── ...
├── V1_F11/
├── V1_T01/
├── ...
└── V1_T05/

13. 实验结果：SSH 与 USB 传输对比

本次操作的观察结果：

对比项目	SSH 网络传输	USB 移动硬盘
数据大小	约4 GB	约4 GB
传输方式	服务器 → 网络 → 本机	服务器 → USB 硬盘
观察到的耗时	约6小时	复制命令约5秒结束
是否依赖网络带宽	是	否
是否需要接触服务器硬件	否	是
是否支持断点续传	是	是
是否需要数据完整性校验	建议	建议

按照观察值简单计算：

SSH 的平均速度约为：

\frac{4096\ \mathrm{MB}}{6\times3600\ \mathrm{s}}
\approx0.19\ \mathrm{MB/s}
]

如果4 GB确实在5秒内完成实际写入，那么对应速度为：

\frac{4096}{5}
\approx819\ \mathrm{MB/s}
]

但需要注意，819 MB/s 对普通机械移动硬盘而言非常高。

因此，这次5秒完成很可能还涉及系统写入缓存、已存在文件被跳过，或者其他影响。

只有确认实际传输字节数，并且将 sync 与安全卸载的时间计入，才能得到可靠的端到端传输速度。

本次实践能够确定的是：使用 USB 复制绕过了原本极慢的网络传输环节，显著改善了数据迁移的操作体验。

14. 常见问题

Q1：为什么服务器能通过 SSH 操作 USB 硬盘？

SSH 提供的是远程终端。

登录服务器后，执行的 lsblk、mount、rsync 等命令实际上都是在服务器本机运行。

因此可以像操作本地 Ubuntu 一样管理服务器连接的 USB 设备。

Q2：为什么复制4 GB的数据只需要几秒？

可能存在三个原因：

USB 本地传输避免了网络瓶颈。
rsync 跳过了已复制且未改变的文件。
Linux 写入缓存使复制命令提前结束，后续仍需将缓存写入硬盘。

因此，应该结合 rsync --stats 和 sync 判断实际情况。

Q3：为什么 ls 显示68K？

ls -lh 不会递归统计子文件夹内容。

查看实际目录大小应使用：

du -sh 目录路径

Q4：SSH 意外断开，USB 复制会停止吗？

如果在普通 SSH 前台运行，复制任务可能被终止。

建议在 tmux 中执行：

tmux new -s usb_copy

这样 SSH 断开后，tmux 中的任务通常仍可以继续。

Q5：如何判断文件有没有复制完整？

Q6：能否直接拔下 USB 硬盘？

不建议。

应该先执行：

sync
sudo umount /mnt/transfer_usb

确认卸载成功后再拔下。

15. 最终操作总结

整个操作可以概括为：

SSH 登录服务器
       │
       ▼
插入 USB 移动硬盘
       │
       ▼
lsblk 确认设备名称
       │
       ▼
mount 挂载移动硬盘
       │
       ▼
df -h 检查剩余空间
       │
       ▼
du -sh 检查源数据大小
       │
       ▼
tmux 创建后台会话
       │
       ▼
rsync 复制实验文件
       │
       ▼
检查实验数量及文件大小
       │
       ▼
rsync --checksum 校验内容
       │
       ▼
sync + umount 安全卸载
       │
       ▼
将硬盘连接本地 Ubuntu
       │
       ▼
rsync 复制到本地项目
       │
       ▼
完成实验数据迁移