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

2017-11-02 09:47:11 +08:00
 alwayshere

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

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

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

10330 次点击
所在节点    程序员
63 条回复
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
@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
一句话,云产品慎用,
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
买个考盘机
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 搬过去直接点

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/402830

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX