目前移动硬盘存储了 16T 的数据，目录结构如下
目前需要迁移到另一个硬盘上，使用过 fastcopy ，速度太慢了，只有 0.06M/s,全部拷完，公司都倒闭了，如下图
求助 v 友还有什么方法，可以快速进行拷贝呢？
 |
1
47jm9ozp 2 天前
dd?
|
 |
2
gtese 2 天前
用 robocopy 命令？ 要么用备份恢复大法？
|
 |
3
malusama 2 天前  5
zip 打包一下再 copy 啊
|
 |
4
xmdbb 2 天前 2
让老板增资，这样公司就没那么快倒闭了
|
 |
5
ihuihui 2 天前
必然是先打包再拷，而且打包不要选压缩。
|
 |
6
wniming 2 天前
dd 到固态
|
 |
7
milkpuff 2 天前
拷贝分区。是否可行
|
 |
8
duanxianze 2 天前
应该有办法整盘克隆吧，走顺序读取会快一些，类似 DiskGenius 似乎有这样的功能
|
 |
9
opengps 2 天前 1
先打个压缩包，你这么小的文件，可能不满一个块大小，实际根本用不了 16T
|
 |
10
bzw875 2 天前
有没有可能是移动硬盘 4kb 读取性能慢，跟写入设备没关系。
先复制 100MB 小文件到 SSD 上看看速度吧 |
 |
11
liyafe1997 2 天前
直接 dd 或用类似 dd 的方式，直接把整个文件系统弄过去，而不是以文件为单位拷
|
 |
12
Leao9203 2 天前 via Android 1
7zip 直接 tar 归档一下，不需要压缩，速度最快，如果有上云需要，也可以做分包，经常用来跟朋友发送大文件用
|
 |
13
MIUIOS 2 天前
小文件，SSD 的噩梦
|
|
14
Leao9203 2 天前 via Android
大量传输小文件太考验源和目标磁盘的 4K 性能了
|
 |
15
0x5c0f 2 天前
试一试 robocopy 多线程模式， 可能会有好的效果
|
 |
16
realJamespond 2 天前
fastcopy 一个 20 年前的工具
|
 |
17
MossFox 2 天前 via Android
迁移到另一个硬盘上，如果是整个盘就这些文件，Windows 直接拿例如 DiskGenius 整个分区复制过去。不用按文件复制。
|
 |
18
lisxour 2 天前
压缩包其实也多大作用，因为还是需要疯狂打开文件疯狂 io ，这是最耗时的，只能直接克隆扇区
|
|
19
opengps 2 天前
 |
 |
20
elron 2 天前
分区 copy
|
 |
21
TsubasaHanekaw 2 天前
直接扇区复制,吃满磁盘连续性能
|
 |
22
rlds 2 天前
两个一样大的硬盘直接试试用 diskgenius 的分区对拷？
|
 |
23
RobinHuuu 2 天前 via iPhone
猜测都是 hdd ？
|
 |
24
Chihaya0824 PRO 1
扇区复制就完事了，别按文件拷贝
|
 |
25
coderwitt 2 天前
哥们，如果你的全是纯文本文件，试试 rsync,直接增量同步，放那跑着就行
如果你是二进制文件，找增量备份或者快照软件，直接对这个目录打个快照，恢复到另一块盘里 |
 |
26
ntedshen 2 天前
把硬盘拆了
能翻倍 |
 |
27
festoney8 2 天前
最快的方法是扇区复制、克隆硬盘，无 4K 读写，推荐在 PE 系统操作
|
 |
28
ritziiiiii 2 天前
条件允许的话，可以暂时把两边的硬盘调换一下，先解燃眉之急
|
 |
29
Eason1900 2 天前
最快的办法就是把移动硬盘物理连接到目标机器上直接使用。
然后再后面慢慢同步去 |
 |
30
deplives 2 天前
先 tar 打包不压缩
再传输，全是小文件，直接考本硬盘 4k 随机读写跟不上的 不行就直接扇区复制 |
 |
31
kzfile 2 天前
看起来像是瓦片
|
 |
32
wxf666 2 天前 1
这种巨量小文件，存进数据库里（如 SQLite ），是不是会好很多？
NTFS 文件系统，每个文件元数据（文件名、长度、时间、权限等）起码占 1KB （ MFT 主文件表里），文件内容还要浪费 < 4KB 用于簇对齐。读写文件还得经过复杂的权限校检、杀毒软件放行等。（估计 WinPE 里会快些） 数据库就轻量很多。8 年前 SQLite [测试]( https://sqlite.org/fasterthanfs.html )，随机读写 10KB 小文件，比文件系统快 35%，节省 20% 空间。转移/备份时也是顺序读写，能全速吃满硬盘。。 |
 |
33
jiagm 2 天前 via Android
@realJamespond fastcopy 目前仍然有在持续开发。
|
 |
34
zhengwenk 2 天前
直接把这个硬盘安装到目标机器得了
|
|
35
wxf666 2 天前
@festoney8 诶，你们觉得，要是能顺序读取硬盘的同时，分析出是哪个文件的内容（应该能通过 MFT 主文件表，获取每个文件数据分布范围吧）。若该文件读完整了，就写入到另一个硬盘里，应该会快很多吧。。
或者，获得所有文件数据分布范围后，按在硬盘上的顺序，依次读取这些文件，磁头不用频繁移动，也能节省大量时间？（也算近乎顺序读取了？） |
 |
36
laminux29 2 天前
前期架构错了，后期就没办法。
首先机械硬盘的随机 IO 就是慢，其次移动机械硬盘的性能更差劲，慢上加慢。 下次这种需求，老老实实换 NVME 吧。 ps.小文件 + 机械硬盘，数据库来了也没辙。 |
|
37
wxf666 2 天前
@jiagm #33 fastcopy 有利用 35 楼说的「分析文件内容在硬盘上的分布，按硬盘顺序读取，减少磁头频繁移动，从而节省大量时间。若文件有碎片，在内存里缓存一部分，读完整再写入」原理吗？感觉是真的可行的。。
如果还没有这样的软件，感觉楼主 @CristianoRonaldo 可以找论坛里，那帮用 AI 很厉害的人，快速写个这样的小工具出来用？ |
|
38
wxf666 2 天前
@laminux29 #36 数据库在随机读写里面的小文件时快不了多少，但作为一个大文件，整体去备份 / 迁移，应该能顺序读取，吃满硬盘性能吧。。
另外，你觉得 35 楼说的「分析文件内容在硬盘上的分布，按硬盘顺序读取，减少磁头频繁移动，从而节省大量时间。若文件有碎片，在内存里缓存一部分，读完整再写入」原理，是可行的吗？ |
 |
39
xkou233 2 天前
winhex 直接拷盘吧 之前拷贝十几个 T 都是这样
|
 |
40
liuzimin 2 天前 via Android
我记得以前 AI 给过我一个 linux 下的思路，是通过一条命令，一边压缩的同时一边解压的方式传输。
|
 |
41
xxbing 2 天前
rsync ???
|
 |
42
zushi000 2 天前
用 diskgens 克隆
|
 |
43
standin000 2 天前
@wxf666 估计软件架构是手搓的数据库，所以一直存放小文件
|
 |
46
zdl0929 2 天前
最快应该是整盘克隆
dd if=/dev/sdX of=/dev/sdY bs=64M status=progress 其次应该是直接 tar 到 对应机器目录（别先 tar 再传，避免中间文件） tar -cf - . | pv | tar -xf - -C /mnt/target |
 |
47
clarkethan 2 天前
如果两边都是 NTFS ，可以考虑用 Clonezilla ，只拷贝使用了的簇，几乎顺序 io ，也没有文件元数据 io 开销
|
|
48
wxf666 2 天前
@festoney8 对呀，就是一个个文件去读，但按照它们内容在硬盘上顺序，去决定文件列表，这样磁头就不需要频繁移动，减少寻道时间，尽量将随机读写，转化成顺序读写了吧？
实在不行，就手动分析物理硬盘上，每个 4K 块数据，属于哪个文件的呗。然后顺序读取分区，提取数据缓存在内存里，哪个文件缓存完了（可能有文件碎片成多个 4K 块），就写入到另一个硬盘里。 别说不可能，各种碎片整理软件，都能知道每个文件每一块碎片，在物理磁盘上的偏移范围。。 |
 |
49
abc0123xyz 2 天前
直接复制硬盘分区
|
 |
50
leeyaunlong 2 天前
你这移动硬盘应该拆出来装 pc 上再复制啊.
|
 |
51
carlojie 2 天前
让我想起来天量数据迁移,使用人工搬运
|
 |
52
Reficul 2 天前
按文件系统拷贝，linux 下面 umount 了之后直接 dd 整个块设备到新硬盘。类似`dd if=/dev/sda of=/dev/sdb`。另外新设备要比老设备大，否则你得先缩文件系统。
按文件拷贝多线程也没用，瓶颈都在 io 上。 |
 |
53
inorobot 2 天前
16T 的机械盘，怎么拷都得几天，还是得上 SSD ，
把移动硬盘拆了，连电脑上用 |
|
54
festoney8 2 天前
@wxf666 #48 我感觉哪怕是按磁盘位置优化过读取顺序，仍然会被 NTFS 元数据影响，比如每个写入操作都会伴随 MFT 、bitmap 的修改，还是会带来随机访问，只有绕过文件系统才能提升速率
|
 |
55
TimePPT PRO 整盘拷贝吧，之前在公司管理过几十 T 稀碎文件，单文件都很小。上个硬盘拷贝机直接插上不用管，很快的。
|
 |
56
Co1e 2 天前
看看评论 学习学习
|
|
57
wxf666 2 天前
@festoney8 #54 Windows 不至于每写一个文件，就强制落盘 $MFT 吧，应该能内存里缓存一段时间，积攒一堆新文件元数据，再一起写入，平摊随机读写成本，转换成大量顺序读写？
其实感觉楼主应该换新方法存储了，否则 NTFS 每次读写都得额外访问 $MFT 、校检权限、杀毒软件放行等，严重拖慢速度，特别是像现在的备份 / 迁移时。。 感觉巨量小文件存数据库里更优，元数据很轻量，且能和文件内容放在一起，减少几次随机 IO （视索引 B+ 树层级而定）。还不用 4K 簇对齐，更充分利用硬盘空间。备份 / 迁移时，还能大文件整体拷贝，吃满硬盘性能。 如果实在要以文件系统形式，对其他程序提供服务，可以用些 fuse 手段。或者参考 RamDisk 它们怎么实现文件读写接口的，它们随机读写文件速度极快，因此这个抽象层应该不会有太多性能损耗。。 现在 AI 这么发达，上述应该不难实现，论坛首页都一堆讨论 AI 的 v 友，请教下他们，或者出点小钱让其帮忙，应该就行了。。 |
|
58
laminux29 2 天前 1
@wxf666 移动机械硬盘的 debuff 被拉满了，再怎么吃满硬盘性能，硬盘性能也就可怜的那一点点。换架构才是解决问题的关键。
35 楼同理，架构没搞好，再优化也没用。 数据证明： 台式机机械硬盘，4k 速度，读平均为 0.7 MB/s ，写平均为 1.5 MB/s 。 SATA-SSD ，4k 速度，读平均为 25 MB/s ，写平均为 70MB/s 。 NVME-SSD ，4k 速度，读平均为 96.9 MB/s ，写平均为 272 MB/s 。 自己看看差了多少倍吧。这就像一句名言：选择大于努力。 |
 |
60
0superx0 1 天前
我能想到的只有 dd 是最快的了
|
 |
61
cheneydog 1 天前
拷完了公司倒闭，永远拷不完公司就永远不会倒闭。
|
 |
62
dode 1 天前
首选硬盘镜像，其次是调小当前分区大小，再硬盘镜像
|
 |
63
eric3797 1 天前
restic 备份到移动硬盘，再从移动硬盘恢复到目标硬盘，速度基本都是满速
|
 |
64
Haku 1 天前
先 tar 再移吧
|
 |
65
zjyl1994 1 天前
看看 diskgenuis 之类的，整个盘克隆，这样顺序读写最快。要不然这么碎的文件隔着一层文件系统快不到哪里去
|
 |
66
5ssl 1 天前
利用 tar for windows 对大量文件进行快速打包
tar -cvf /wwwroot.tar d:/wwwroot |
 |
67
oisadfo 1 天前
什么平台，什么文件系统，windows 的 ntfs 等文件系统，有很多工具，搜下 分区克隆或者磁盘克隆
|
 |
68
zxjxzj9 1 天前
问了下 ai 有个点子我觉得可以，就是自己定义一个简单的二进制文件把数据打包进去（不是压缩包协议）然后整块传输。sqlite 有事务这个机制在估计也不是很适合
|
 |
69
kasusa 1 天前
硬盘对拷设备来搞。
放那慢慢拷。几天完事了。 |
 |
70
CristianoRonaldo OP 谢谢各位，今天上午试了一下 diskgenuis ，整盘拷贝，速度非常快，2000MB/min ，
这部分数据的使用，会挂 ftp ，提供给业务系统，想过入库 minio 这些文件系统，但是太慢了，就直接挂 FTP 了。  |
|
71
CristianoRonaldo OP 谢谢各位，今天上午试了一下 diskgenuis ，整盘拷贝，速度非常快，2000MB/min ，
 ,这部分数据的使用，会挂 ftp ，提供给业务系统，想过入库 minio 这些文件系统，但是太慢了，就直接挂 FTP 了。 |
 |
73
yulgang 1 天前
当然是做磁盘镜像啊
|
 |
74
lswlray 1 天前
@CristianoRonaldo 你是用 DG 的 克隆磁盘 ？克隆分区？ 扇区复制？
|
|
75
CristianoRonaldo OP @lswlray #74 克隆磁盘不行，两边盘大小不一样，选的复制文件
|
 |
76
dosmlp 1 天前
分区克隆，然后再在目标硬盘上调整分区大小就行了
|
 |
77
Gilfoyle26 1 天前
《只有 0.06M/s,全部拷完，公司都倒闭了》公司倒闭了，就不要拷贝了
 |
|
78
festoney8 1 天前
@CristianoRonaldo #71 这个速度是被 usb2.0 限制了吗，我上次 DG 操作速度在 9000 以上
|
 |
79
rioufbi 1 天前
压缩软件了解一下
|
 |
80
lixingcai 1 天前
之前用 robocopy 好使，直接把线程拉满，快的一 b
|
 |
81
chouxiang99 1 天前
7zip 压缩的时候 可以选择压缩质量 改成仅存储 这样不会进行压缩 只是打包成一个大包 速度很快 然后在整个大包拷贝 速度应该就快了 可以参考一下
|
 |
82
yuanxing008 1 天前
两个方案：打包对拷 或者直接 dg 操作硬盘对拷
|
|
83
wxf666 1 天前
@CristianoRonaldo #75 是如下图那样，克隆分区——按文件复制（可消除碎片）吗？
这速度可以啊，感觉应该就是巨量小文件的标准迁移方法了！学到了！ --- @festoney8 #78 诶，你说 DG 这办法，是不是类似上面说的，一边扫描原分区，一边分析所属文件，一边用自己的算法，批量积攒一堆小文件后，直接修改目标盘 NTFS 。。 毕竟速度这么快，肯定是顺序读写。又能消除文件碎片，肯定不是按原样拷贝 4K 块 / 扇区。 目标盘巨量小文件也能写这么快，肯定不是一会儿跑去写 $MFT ，一会儿写几 KB 文件内容。 --- @laminux29 #58 我知道机械硬盘 4K 随机读写差，巨量小文件又很吃这个，换固态肯定有飞一般的提升。 但在此之前，也需要从原机械盘读出来不是？ 感觉楼主这个做法，应该是标准解了。。 ---  |
|
84
festoney8 1 天前
@wxf666 #83 那要看 DG 的操作有没有调用 Win32 API 了，DG 复制文件时速度快可能和无操作系统开销有关，它高度依赖 MFT ，或许软件内部有优化
|
|
85
wxf666 1 天前
@festoney8 #84 DG 应该自己实现了一套 NTFS 读写算法的。。
上次我在微 PE 里，用可能有点老的 DG ，调整 Win11 分区大小。（那个 PE 里系统自带的分区调整用不了，说无服务还是啥） 结果重启后 Win11 进不去了。再次进入 PE ，文件管理器也不识别那个分区了，但 DG 还是能读出来里面的文件，我也靠这货备份数据，最后重装了。。 怀疑 Win11 的 NTFS 版本有新特性，老 DG 不认识，调整分区大小时破坏了。。  |
 |
86
niubee1 1 天前
用 dd 啦
|
Select Language