首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Coding
V2EX  ›  程序员

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

  •  
  •   alwayshere · 2017-11-02 09:47:11 +08:00 · 8302 次点击
    这是一个创建于 774 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    63 回复  |  直到 2017-11-03 22:10:10 +08:00
        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-02 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
    FifiLyu   2017-11-02 10:56:11 +08:00
    rsync 就行。几十台服务器(几十 T 小文件)可以在几天内数据全部迁移。没任何丢失和损坏。非常成熟的方法。
        26
    lscomeon   2017-11-02 11:01:58 +08:00
    @nonsense 这种方法完全行不通
        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
    moonsn1994   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
    永远不要忽略一辆载满磁带的在高速公路上飞驰的卡车的带宽
    http://news.mydrivers.com/1/544/544117.htm

    我记得 google、amazon 经常做这样的事。
        44
    sumu   2017-11-02 14:36:21 +08:00
    @wspsxing +1。运营环境数据就是这么备份的,pigz+rsync
        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
    @FifiLyu (几十 T 小文件)可以在几天内数据全部迁移,你这个是在内网才能做到吧?
    跨服务商,估计会很慢?


    @sumu rsync 支持传输前压缩,同步后再解压?
        55
    Havee   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
    @Seymer 这题太简单了(而且和本贴其实关系不大。)开 http 反代然后 aria2 多源分块下载就行,不说 100GB 的文件,就算是单个 20TB 的文件也可以像这样高效分段下载(最多重新编译 aria2,增加分块数量)。

    @gnawe rsync 的速度很好的,只要你网络带宽够大,硬件配置够好,跑满不难。
    rsync 自带压缩功能。
    -z, --compress compress file data during the transfer
    --compress-level=NUM explicitly set compression level
        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
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3973 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 30ms · UTC 09:56 · PVG 17:56 · LAX 01:56 · JFK 04:56
    ♥ Do have faith in what you're doing.