1.2T 的数据， 117 万个文件，嵌套 3 级文件夹，想转移服务器，最高效不会有任何文件损失的文件转移方式是什么？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2580 天前的主题，其中的信息可能已经有所发展或是发生改变。

目前这台 centos6.8 服务器配置太低已经运转很吃力了，想转移一台好点的服务器，当然不要说什么快递硬盘这么不现实的话，服务器都是一些细小文件，存放在一个叫 static 文件夹里，存放路径形式如：static/ab/cd/ef/blahblah.zip 这样三级文件夹嵌套的形式，现在转移服务器要求如下：

不能有任何一个文件的损失
如果转移途中有网络掉线 or 中断，能否实现断点续传之类的从上次掉线的节点继续转移
转移完成后，怎样检测新服务器的“ static ”文件夹和原旧服务器上的“ static ”文件夹一模一样，包括文件数量和存放位置以及文件大小，不会存在 0 byte 的 blahblah.zip 这样的空壳文件

求好心 V 友解答一下，我 Linux 不是太精通，先谢了

文件

Static

服务器

转移

63 条回复 • 2017-11-03 22:10:10 +08:00

pming1

2017-11-02 09:49:17 +08:00

物理机的话，把硬盘转过去

ynyounuo

2017-11-02 09:49:30 +08:00 via iPhone

rsync

fengjianxinghun

2017-11-02 09:49:41 +08:00

rsync

Leafove

2017-11-02 09:53:42 +08:00

联系服务商拿硬盘

gouchaoer

2017-11-02 09:54:03 +08:00 via Android

手写一个脚本遍历放数据库，完了一个个检查，不多

liuyes

2017-11-02 09:54:39 +08:00

用 ftp 感觉也行

jyf

2017-11-02 09:57:56 +08:00

rsync 吧可以考虑在新的机器上 /static 单独占个分区将来要快速迁移直接 dd

kiwi95

2017-11-02 09:57:58 +08:00 via Android

rsync，不放心就 sync 两遍三遍的:-D

domty

2017-11-02 10:00:10 +08:00

你把文件的路径文件 hash 遍历一遍存下来，然后挨个同步。
同步完成后在新服务器上重做一遍同样的遍历和原数据进行比对，缺了的或者文件 hash 对不上的单个文件重新同步就行。
至于同步的方法有很多，楼上说的 rsync 就不错。

mol310

2017-11-02 10:01:23 +08:00

rsync -P 断点续传

crbee

2017-11-02 10:06:00 +08:00

同步应该没有比 rsync 更好的方法了
但其实直接拿硬盘放到新机房更方便，如果怕硬盘期间损坏可以增加一块硬盘备份再快递硬盘。

danielmiao

2017-11-02 10:07:22 +08:00

远程的话，就是新机器建 NFS，然后在旧机器上挂载以后，用 dd 去拷贝。。但是不支持断点

huijiewei

2017-11-02 10:08:50 +08:00

lsyncd 吧，亲测好用

http://seanlook.com/2015/05/06/lsyncd-synchronize-realtime/

chih

2017-11-02 10:13:59 +08:00 via Android

rsync

manzhiyong

2017-11-02 10:15:39 +08:00

顺丰？

bullfrog

2017-11-02 10:32:17 +08:00

lftp

defunct9

2017-11-02 10:34:58 +08:00

rsync

defunct9

2017-11-02 10:35:58 +08:00

开 ssh，我可以帮你弄，用 rsync，我们公司 35TB 的数据都是这么弄的

Seymer

2017-11-02 10:37:25 +08:00

前段时间看到过这么一个解决方案，个人没有实践，仅供参考。

eslizn

2017-11-02 10:39:56 +08:00

云服务器也是可以物理迁移的：
https://aws.amazon.com/cn/snowball/

ray1888

2017-11-02 10:43:09 +08:00

用 rsync 吧，方案已经很成熟了

AlphaIce

2017-11-02 10:45:39 +08:00

rsync

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 性能吧.

rffan

2017-11-02 10:53:03 +08:00

rsync 或者自写脚本对比 sha1 值。嗯，物理机器，还是物理转移的好。直接硬盘甩过去，开心。

FifiLyu

2017-11-02 10:56:11 +08:00

rsync 就行。几十台服务器（几十 T 小文件）可以在几天内数据全部迁移。没任何丢失和损坏。非常成熟的方法。

lscomeon

2017-11-02 11:01:58 +08:00

@nonsense 这种方法完全行不通

MarioxLinux

2017-11-02 11:06:06 +08:00

rsync 可以满足

rrfeng

2017-11-02 11:14:49 +08:00

没说传到哪里去。
两台电脑挨着吗？还是隔很远？

xenme

2017-11-02 11:19:05 +08:00

快递，硬盘镜像应该是最快的。

pynix

2017-11-02 11:22:42 +08:00

建议花点流量钱直接上传到云，比如某牛，某 3，以后就在云上提供服务了。。。。避免再次出现迁移。。。

8355

2017-11-02 11:42:55 +08:00

先写个脚本记录 md5 或者 sha1 值遍历所有文件然后 rsync 以后再检查一遍就可以了. 像你这种情况最好还是上云用对象储存保存文件不管是可靠性还是可扩展性都比你自己储存的要好. 你的文件数量很大以后随着业务增长越来越多的时候你每次扩容都要迁怎么办

moonsn

2017-11-02 12:32:37 +08:00

快递硬盘

Hermann

2017-11-02 12:41:44 +08:00

Allway Sync

这个软件可以实现吗，我用它备份自己的网站

heiyutian

2017-11-02 12:49:22 +08:00 via Android

无损压缩再传再解压

gamexg

2017-11-02 12:56:29 +08:00 via Android

rsync
即使其他方式实现了也建议最后用 rsync 同步次确认一致。

janxin

2017-11-02 13:02:00 +08:00

当然不要说什么快递硬盘这么不现实的话我觉得很现实啊，自己的服务器就这么搞

云服务器另说

techeek

2017-11-02 13:12:08 +08:00

我前几天是 tar 打包……然后 http 传输……近 1T 的数据……

stanjia

2017-11-02 13:15:44 +08:00

rsync

likuku

2017-11-02 13:46:16 +08:00

物理硬盘快递什么，最后还是得用 rsync -avP 复制过去，1.2TB 很快的啦...

再者可对源盘的文件作 find + shasum 作个 hash 列表。文件复制完毕，再依照 hash 列表文件作一次校验。

memorybox

2017-11-02 13:50:34 +08:00

rsync

dd,tar,抠硬盘对拷,clonezilla 都用过，结论还是 rsync 最方便。

wspsxing

2017-11-02 13:58:49 +08:00

pigz/pixz 等可以并行压缩, rsync 同步数据.

flyingghost

2017-11-02 14:05:26 +08:00

永远不要忽略一辆载满磁带的在高速公路上飞驰的卡车的带宽
http://news.mydrivers.com/1/544/544117.htm

我记得 google、amazon 经常做这样的事。

sumu

2017-11-02 14:36:21 +08:00

@wspsxing +1。运营环境数据就是这么备份的，pigz+rsync

usernametoolong

2017-11-02 15:03:20 +08:00

1、tar+ssh 隧道一边打包一边解压传过去。
2、rsync 同步
3、用 find 命令把所的文件路径摸一遍存起来，走 http 协议用 wget 过一遍，再用 rsync 做一次对比。
4、拆硬盘。如果网络不够快那只有拆硬盘最方便了。

这么多重要的数据平常都不做同步备份的？？？手动黑人问号。

s7lx

2017-11-02 15:55:06 +08:00

我提个题主自己可能都没注意到的问题，传输数据的时候，可能业务还没有间断，文件还有读写？所以是不是业务还不能停？

xmoiduts

2017-11-02 16:22:15 +08:00 via Android

@Seymer 有没有 oss ？或许综合下来能拿到更低的成本。图中方法就算开满了 20 台小鸡（ 20x5=100Mbps ）也要 20 天才能搞出来。实际问题还是如何搞到便宜流量。

ohhe

2017-11-02 16:29:50 +08:00

rsync 几个小时搞定，带宽弄到最大。
1T 不算多。

anmaz

2017-11-02 16:38:01 +08:00 via Android

一句话，云产品慎用，

sopato

2017-11-02 17:35:39 +08:00

rsync 啊，没有比它更好的方案了。

kaneg

2017-11-02 18:07:25 +08:00

这个活非 rsync 莫属

chcx

2017-11-02 18:57:57 +08:00

rsync 同步下就完了。

meisky6666

2017-11-02 19:20:19 +08:00 via Android

买个考盘机

gnawe

2017-11-02 20:03:58 +08:00

@FifiLyu （几十 T 小文件）可以在几天内数据全部迁移，你这个是在内网才能做到吧？
跨服务商，估计会很慢？

@sumu rsync 支持传输前压缩，同步后再解压？

Havee

2017-11-02 20:14:34 +08:00

先 dd 成一个包，再 rsync 断点续传，这样好点。否则被小文件弄懵。

Admstor

2017-11-02 21:06:16 +08:00

其实快递硬盘是最方便的...不知道为何不接受这个方案,是接触不到物理机器?

数据完整性就每个文件都算个 hash 然后对比
但是这个时间就挺长的,而且如果你对数据要求特别高甚至 1bit 都不能错,一个文件 hash 几次做比较,防止偶然性的磁盘错误或者内存错误...

wmhx

2017-11-02 21:20:16 +08:00

1,硬盘对拷后快递.
2,按一定方式压缩成 2G 大小的文件,然后下载, 最后比对 hash.
3,写程序逐个下载比对

msg7086

2017-11-03 04:34:56 +08:00

@Seymer 这题太简单了（而且和本贴其实关系不大。）开 http 反代然后 aria2 多源分块下载就行，不说 100GB 的文件，就算是单个 20TB 的文件也可以像这样高效分段下载（最多重新编译 aria2，增加分块数量）。

@gnawe rsync 的速度很好的，只要你网络带宽够大，硬件配置够好，跑满不难。
rsync 自带压缩功能。
-z, --compress compress file data during the transfer
--compress-level=NUM explicitly set compression level

msg7086

2017-11-03 04:40:12 +08:00

To 楼主：
rsync 同步的时候会比对文件，文件大小一样，修改时间一样的，会自动跳过，不一样的，才会复制。

所以最坏的情况下，你同步完成后再同步一次，如果没有任何文件传输，那就解决了你上面列的所有三条疑问了。

甚至你可以跑着业务的时候传输，全部传完以后，业务停机，再快速同步一次，就可以切服务器了，downtime 的时间几乎没有的。

xman99

2017-11-03 09:18:09 +08:00

凌晨执行 rsync 吧，这种可以慢慢迁移。
实体机在自己身边，HDD 搬过去直接点

mingl0280

2017-11-03 13:02:15 +08:00

首先，tar+http 可以满足，rsync 也可以满足
其次，MD5 或者 sha1 做个目录哈希就完了……

flyingheart

2017-11-03 15:03:54 +08:00

rsync，对服务器影响很小

ritaswc

2017-11-03 22:10:10 +08:00

rsync 需要帮助请联系我 blog.yinghualuo.cn