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