1.2T 的数据， 117 万个文件，嵌套 3 级文件夹，想转移服务器，最高效不会有任何文件损失的文件转移方式是什么？
alwayshere 2017-11-02 09:47:11 +08:00 10972 次点击这是一个创建于 2978 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前这台 centos6.8 服务器配置太低已经运转很吃力了，想转移一台好点的服务器，当然不要说什么快递硬盘这么不现实的话，服务器都是一些细小文件，存放在一个叫 static 文件夹里，存放路径形式如：static/ab/cd/ef/blahblah.zip 这样三级文件夹嵌套的形式，现在转移服务器要求如下：
- 不能有任何一个文件的损失
- 如果转移途中有网络掉线 or 中断，能否实现断点续传之类的从上次掉线的节点继续转移
- 转移完成后，怎样检测新服务器的“ static ”文件夹和原旧服务器上的“ static ”文件夹一模一样，包括文件数量和存放位置以及文件大小，不会存在 0 byte 的 blahblah.zip 这样的空壳文件
求好心 V 友解答一下，我 Linux 不是太精通，先谢了
 | 1 pming1 2017-11-02 09:49:17 +08:00 物理机的话，把硬盘转过去 |
 | 2 ynyounuo 2017-11-02 09:49:30 +08:00 via iPhone  4 rsync |
 | 3 fengjianxinghun 2017-11-02 09:49:41 +08:00 rsync |
 | 4 Leafove 2017-11-02 09:53:42 +08:00 联系服务商拿硬盘 |
 | 5 gouchaoer 2017-11-02 09:54:03 +08:00 via Android 手写一个脚本遍历放数据库，完了一个个检查，不多 |
 | 6 liuyes 2017-11-02 09:54:39 +08:00 用 ftp 感觉也行 |
 | 7 jyf 2017-11-02 09:57:56 +08:00 rsync 吧 可以考虑在新的机器上 /static 单独占个分区 将来要快速迁移 直接 dd |
 | 8 kiwi95 2017-11-02 09:57:58 +08:00 via Android rsync，不放心就 sync 两遍三遍的:-D |
 | 9 domty 2017-11-02 10:00:10 +08:00 你把文件的路径 文件 hash 遍历一遍存下来，然后挨个同步。 同步完成后在新服务器上重做一遍同样的遍历和原数据进行比对，缺了的或者文件 hash 对不上的单个文件重新同步就行。 至于同步的方法有很多，楼上说的 rsync 就不错。 |
 | 10 mol310 2017-11-02 10:01:23 +08:00 rsync -P 断点续传 |
 | 11 crbee 2017-11-02 10:06:00 +08:00 2 同步应该没有比 rsync 更好的方法了 但其实直接拿硬盘放到新机房更方便，如果怕硬盘期间损坏可以增加一块硬盘备份再快递硬盘。 |
 | 12 danielmiao 2017-11-02 10:07:22 +08:00 远程的话，就是新机器建 NFS，然后在旧机器上挂载以后，用 dd 去拷贝。。但是不支持断点 |
 | 13 huijiewei 2017-11-02 10:08:50 +08:00 |
 | 14 chih 2017-11-2 10:13:59 +08:00 via Android rsync |
 | 15 manzhiyong 2017-11-02 10:15:39 +08:00 顺丰？ |
 | 16 bullfrog 2017-11-02 10:32:17 +08:00 lftp |
 | 17 defunct9 2017-11-02 10:34:58 +08:00 rsync |
| 18 defunct9 2017-11-02 10:35:58 +08:00 开 ssh，我可以帮你弄，用 rsync，我们公司 35TB 的数据都是这么弄的 |
 | 19 Seymer 2017-11-02 10:37:25 +08:00 前段时间看到过这么一个解决方案，个人没有实践，仅供参考。  |
 | 20 eslizn 2017-11-02 10:39:56 +08:00 云服务器也是可以物理迁移的： https://aws.amazon.com/cn/snowball/ |
 | 21 ray1888 2017-11-02 10:43:09 +08:00 用 rsync 吧，方案已经很成熟了 |
 | 22 AlphaIce 2017-11-02 10:45:39 +08:00 rsync |
 | 23 nonsense 2017-11-02 10:50:26 +08:00 nohup tar -cf abc.tar static & 弄成一个文件,避免传输过程中元数据 inode 频繁操作导致时间慢几倍 内容要压缩的话 nohup tar -c static | gzip -2 > abc.tgz & 解压时的 inode 操作就逃不掉了吧, tar 应该是单线程,平时使用 find 命令的时候发现比较快,可能是多线程的吧,但是小文件 inode 操作还是取决于硬盘 IOPS 性能吧. |
 | 24 rffan 2017-11-02 10:53:03 +08:00 rsync 或者自写脚本对比 sha1 值。嗯，物理机器，还是物理转移的好。直接硬盘甩过去，开心。 |
 | 25 mN71eOOprFyMsnPx 2017-11-02 10:56:11 +08:00 rsync 就行。几十台服务器（几十 T 小文件）可以在几天内数据全部迁移。没任何丢失和损坏。非常成熟的方法。 |
 | 27 MarioxLinux 2017-11-02 11:06:06 +08:00 rsync 可以满足 |
 | 28 rrfeng 2017-11-02 11:14:49 +08:00 没说传到哪里去。 两台电脑挨着吗？还是隔很远？ |
 | 29 xenme 2017-11-02 11:19:05 +08:00 快递，硬盘镜像应该是最快的。 |
 | 30 pynix 2017-11-02 11:22:42 +08:00 建议花点流量钱直接上传到云，比如 某牛，某 3，以后就在云上提供服务了。。。。避免再次出现迁移。。。 |
 | 31 8355 2017-11-02 11:42:55 +08:00 先写个脚本记录 md5 或者 sha1 值 遍历所有文件 然后 rsync 以后再检查一遍就可以了. 像你这种情况最好还是上云用对象储存保存文件 不管是可靠性还是可扩展性都比你自己储存的要好. 你的文件数量很大 以后随着业务增长越来越多的时候你每次扩容都要迁怎么办 |
 | 33 moonsn 2017-11-02 12:32:37 +08:00 快递硬盘 |
 | 34 Hermann 2017-11-02 12:41:44 +08:00 Allway Sync 这个软件可以实现吗，我用它备份自己的网站 |
 | 35 heiyutian 2017-11-02 12:49:22 +08:00 via Android 无损压缩再传再解压 |
 | 36 gamexg 2017-11-02 12:56:29 +08:00 via Android rsync 即使其他方式实现了也建议最后用 rsync 同步次确认一致。 |
 | 37 janxin 2017-11-02 13:02:00 +08:00 当然不要说什么快递硬盘这么不现实的话 我觉得很现实啊，自己的服务器就这么搞 云服务器另说 |
 | 38 techeek 2017-11-02 13:12:08 +08:00 我前几天是 tar 打包……然后 http 传输……近 1T 的数据…… |
 | 39 stanjia 2017-11-02 13:15:44 +08:00 rsync |
 | 40 likuku 2017-11-02 13:46:16 +08:00 物理硬盘快递什么，最后还是得用 rsync -avP 复制过去，1.2TB 很快的啦... 再者可对源盘的文件作 find + shasum 作个 hash 列表。文件复制完毕，再依照 hash 列表文件作一次校验。 |
 | 41 memorybox 2017-11-02 13:50:34 +08:00 rsync dd,tar,抠硬盘对拷,clonezilla 都用过，结论还是 rsync 最方便。 |
 | 42 wspsxing 2017-11-02 13:58:49 +08:00 pigz/pixz 等可以并行压缩, rsync 同步数据. |
 | 43 flyingghost 2017-11-02 14:05:26 +08:00 |
 | 45 usernametoolong 2017-11-02 15:03:20 +08:00 1、tar+ssh 隧道 一边打包一边解压传过去。 2、rsync 同步 3、用 find 命令把所的文件路径摸一遍存起来，走 http 协议用 wget 过一遍，再用 rsync 做一次对比。 4、拆硬盘。 如果网络不够快那只有拆硬盘最方便了。 这么多重要的数据平常都不做同步备份的？ ？？ 手动黑人问号。 |
 | 46 s7lx 2017-11-02 15:55:06 +08:00 我提个题主自己可能都没注意到的问题，传输数据的时候，可能业务还没有间断，文件还有读写？所以是不是业务还不能停？ |
 | 47 xmoiduts 2017-11-02 16:22:15 +08:00 via Android @Seymer 有没有 oss ？或许综合下来能拿到更低的成本。图中方法就算开满了 20 台小鸡（ 20x5=100Mbps ）也要 20 天才能搞出来。实际问题还是如何搞到便宜流量。 |
 | 48 ohhe 2017-11-02 16:29:50 +08:00 rsync 几个小时搞定，带宽弄到最大。 1T 不算多。 |
 | 49 anmaz 2017-11-02 16:38:01 +08:00 via Android 一句话，云产品慎用， |
 | 50 sopato 2017-11-02 17:35:39 +08:00 rsync 啊，没有比它更好的方案了。 |
 | 51 kaneg 2017-11-02 18:07:25 +08:00 这个活非 rsync 莫属 |
 | 52 chcx 2017-11-02 18:57:57 +08:00 rsync 同步下就完了。 |
 | 53 meisky6666 2017-11-02 19:20:19 +08:00 via Android 买个考盘机 |
 | 54 gnawe 2017-11-02 20:03:58 +08:00 |
 | 55 Busy 2017-11-02 20:14:34 +08:00 先 dd 成一个包，再 rsync 断点续传，这样好点。否则被小文件弄懵。 |
 | 56 Admstor 2017-11-02 21:06:16 +08:00 其实快递硬盘是最方便的...不知道为何不接受这个方案,是接触不到物理机器? 数据完整性就每个文件都算个 hash 然后对比 但是这个时间就挺长的,而且如果你对数据要求特别高甚至 1bit 都不能错,一个文件 hash 几次做比较,防止偶然性的磁盘错误或者内存错误... |
 | 57 wmhx 2017-11-02 21:20:16 +08:00 1,硬盘对拷后快递. 2,按一定方式压缩成 2G 大小的文件,然后下载, 最后比对 hash. 3,写程序逐个下载比对 |
 | 58 msg7086 2017-11-03 04:34:56 +08:00 |
| 59 msg7086 2017-11-03 04:40:12 +08:00 2 To 楼主： rsync 同步的时候会比对文件，文件大小一样，修改时间一样的，会自动跳过，不一样的，才会复制。 所以最坏的情况下，你同步完成后再同步一次，如果没有任何文件传输，那就解决了你上面列的所有三条疑问了。 甚至你可以跑着业务的时候传输，全部传完以后，业务停机，再快速同步一次，就可以切服务器了，downtime 的时间几乎没有的。 |
 | 60 xman99 2017-11-03 09:18:09 +08:00 凌晨执行 rsync 吧， 这种可以慢慢迁移。 实体机在自己身边，HDD 搬过去直接点 |
 | 61 mingl0280 2017-11-03 13:02:15 +08:00 首先，tar+http 可以满足，rsync 也可以满足 其次，MD5 或者 sha1 做个目录哈希就完了…… |
 | 62 flyingheart 2017-11-03 15:03:54 +08:00 rsync，对服务器影响很小 |
 | 63 ritaswc 2017-11-03 22:10:10 +08:00 rsync 需要帮助请联系我 blog.yinghualuo.cn |
Select Language