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

如何确保移动硬盘的大量数据不会损坏?

  •  
  •   kerrspace · 2022-07-26 05:42:32 +08:00 · 5962 次点击
    这是一个创建于 859 天前的主题,其中的信息可能已经有所发展或是发生改变。

    小弟有一个问题,假设我不信任网盘(倒闭或者加密压缩文件都被乱杀和谐,百度云盘经常干这事)和类似群晖(故障毁盘,扩展能力有限)这样的软件,我就使用最原始的手工的办法,每一个移动硬盘都准备一个备份盘,譬如说 ABCDE 五个硬盘,我就有完全对称的 abcde 五个备份盘。

    现在问题来了,这样备份肯定隔一段时间就要确定数据有没有损坏,譬如对比 A 和 a ,如果 A 有坏道导致数据损坏,就 copy a 的内容到 A 。如果长时间不 check 肯定最后 a 和 A 都要损坏,备份就失去意义了。所以要经常比对

    大家有什么好的对比检测文件是否有损坏的方案吗?

    譬如说我全部打包成压缩包,只要压缩包能正常解压能不能说明文件一定没有损坏? step 1. 统计 A 中能正常解压的压缩包 step 2. 统计 a 中能正常解压的压缩包 step 3. 把属于 A 但不属于 a 的压缩包从 A 复制到 a step 4. 把属于 a 但不属于 A 的压缩包从 a 复制到 A

    59 条回复    2022-07-27 15:36:38 +08:00
    singerll
        1
    singerll  
       2022-07-26 06:03:07 +08:00 via Android   ❤️ 4
    如果我没有看错,你是在自己重新造一遍 raid1 。。。
    datocp
        2
    datocp  
       2022-07-26 06:04:56 +08:00 via Android
    我想破脑袋用一些 crc 校验软件,将同一份文件复制占满同一分区,通过校验这些文件的 crc 值来确认是否坏了。
    方法是有了,还没在工作中使用过。
    wizardyhnr
        3
    wizardyhnr  
       2022-07-26 06:05:04 +08:00
    纯校验 md5
    par2 可以产生冗余校验文件,可以起到校验和修复的作用(错误率低于冗余度都可以修复)。
    winrar 也有冗余度的选项,不愿意研究 par2 的用 winrar 也可以。
    文件系统如 btrfs scrub 可有校验数据的功能。
    另外存档打包不推荐用固实压缩。
    kerrspace
        4
    kerrspace  
    OP
       2022-07-26 06:14:05 +08:00
    @singerll 你去买个群晖那种磁盘阵列机器 他能插的接口是有限的啊 4 ,5 块顶天了吧 而我这边手动做可以无限多块硬盘。。而且知乎上群晖出错故障直接毁盘的案例也有不少了。
    runningowl
        5
    runningowl  
       2022-07-26 06:16:16 +08:00   ❤️ 1
    所以才有 3-2-1 rule 啊,3 个备份,2 种存储,1 份离线

    再次一些,备份盘就老实放着,日用盘 5 年一换总是保险的,7*24 的就 3 年一换

    比如,
    3 年了,
    买新备份盘
    原备份盘变日用盘
    原日用盘被迫之
    singerll
        6
    singerll  
       2022-07-26 06:20:01 +08:00 via Android
    @kerrspace 个人版的存储已经有八盘位的了,商用存储的话,你想要多少,就给你加多少。
    kerrspace
        7
    kerrspace  
    OP
       2022-07-26 06:21:46 +08:00
    @runningowl 你这种有个 bug 就是硬盘损坏模式未必就跟使用时间长度有关系 你的备份盘可能买来就是有坏道的 这部分 damage 的数据又会在备用盘变日用盘的时候遗传给下一代备用盘 演化的终点就是数据面目全非
    wxf666
        8
    wxf666  
       2022-07-26 06:26:05 +08:00
    @kerrspace 假如一个压缩包内容是 ABC ,A 盘内容变成 BBC ,a 盘内容变成 ABB ,咋办?
    msg7086
        9
    msg7086  
       2022-07-26 06:27:58 +08:00
    @kerrspace #7 这边建议你了解一下什么是坏道。
    坏道不是数据内容变了。
    ryd994
        10
    ryd994  
       2022-07-26 06:31:25 +08:00   ❤️ 1
    恭喜你重新发明了 ZFS

    #4 “他能插的接口是有限的啊 4 ,5 块顶天了吧”

    你大概没见过 SAS HBA 卡配合 expander 连接上百块硬盘……
    wxf666
        11
    wxf666  
       2022-07-26 06:42:34 +08:00
    @kerrspace 根据 @wizardyhnr #3 所说,利用 par2 (类似 winrar 冗余校错)写个小脚本,来实现:

    (对于 A 盘任意文件 D:/path/src_file ,应对应于 a 盘中的 E:/path/src_file.par2 冗余校检文件)

    1. src_file.par2 不存在,则自动生成( 50% 冗余度?允许 < 50% 错误?)

    2. src_file.par2 上次访问 /修改时间已超过 30 天,则校检一次(并自动修复错误),并更新访问 /修改时间

    3. src_file 不存在,则删除 src_file.par2

    效果会好吗?
    wizardyhnr
        12
    wizardyhnr  
       2022-07-26 07:00:45 +08:00
    @wxf666 par2 是适合冷数据备份的,usenet 上大量使用,光盘刻录有 dvdisaster 也是同样的原理。冷数据备份极致就是 3-2-1 rule 加 par2 。
    SuperMild
        13
    SuperMild  
       2022-07-26 07:59:54 +08:00
    我的做法是,把文件的 hash (比如 MD5 之类的)记录在 sqlite 数据库中,然后定期检查(分批检查,比如每天只检查 5GB ,循环检查),发现错误就从备份中获取正确的文件进行自动修复。
    SuperMild
        14
    SuperMild  
       2022-07-26 08:03:02 +08:00
    另外我总结了 “网盘备份的缺点” 和 “本地备份的优点” https://v2ex.com/t/774938
    wxf666
        15
    wxf666  
       2022-07-26 08:03:13 +08:00
    @wizardyhnr 能用 100% 冗余度 代替原文件吗?否则出现所有备份各损坏一部分,咋办
    neteroster
        16
    neteroster  
       2022-07-26 08:15:10 +08:00 via Android
    zfs or btrfs
    beijiaoff
        17
    beijiaoff  
       2022-07-26 08:22:45 +08:00
    你这需求太夸张了。硬盘不坏,数据出错的概率非常小的。
    knives
        18
    knives  
       2022-07-26 08:25:07 +08:00
    基本可以参考冗余校验的机制(也叫纠删码什么的),比如 ZFS 的 raidz 或者 snapraid ,这俩都提供了 scrub 命令用来验证磁盘上数据是否损坏。

    当然这个也不是万能的,如果损坏的数据操过了冗余数据的比例,该丢的还得丢。
    yaoyao1128
        19
    yaoyao1128  
       2022-07-26 08:34:11 +08:00 via iPhone

    请问您说的是不是 winrar 恢复卷 和 校验压缩文件?
    datocp
        20
    datocp  
       2022-07-26 08:38:06 +08:00
    去年尝试用将同一个文件复制填充整个硬盘分区来校验它们的 sfv 值来确定文件的损坏是否就是硬盘损坏。当然没真正应用过。。。
    当时找的还有一些辐助软件
    digup
    fsum
    wxchecksums
    wxmsw242
    disk-filltest
    dummy12


    multicopy1.cmd
    @echo off
    echo.
    if NOT "%2"=="" goto next1

    echo %0 will make the specified number of copies of a file to (by default) the current folder
    echo The copies will have '(Copy n) ' added at the beginning of the filename, where 'n' is the count
    echo .
    echo Useage: %0 copies source_file [destination folder]
    echo example: %0 10 test.txt C:\temp
    goto end

    :next1
    if EXIST ".\%2" goto next2
    echo file %2 not found
    goto end

    :next2
    set count=%1
    set destination=%3
    if "%3"=="" set destination=.

    :repeat
    @echo on
    ::copy %2 "%destination%\(Copy %count%) %2"
    copy %2 "%destination%\%2_%count%"
    @echo off
    ::pause

    set /a count=%count%-1
    if %count% LEQ 0 echo Requested number of copies (%1) have been made.
    if %count% LEQ 0 goto end

    goto repeat

    :end
    cr0wd
        21
    cr0wd  
       2022-07-26 08:53:01 +08:00 via Android
    想到了 SnapRAID
    bigdoing
        22
    bigdoing  
       2022-07-26 08:54:58 +08:00 via iPhone
    受不了你们搞这么复杂干嘛,多余的设备,维护精力,折现给我,我教你

    把文件加密备份到云盘不就好了吗,一般情况是破解不了的,密码用 1024 位,单独存另一个地方,手机里也行

    本地有用的数据,云端永远有一份离线数据,简单又干净

    还不放心,就隔一段时间下载下来,对比 md5

    快给钱
    bigdoing
        23
    bigdoing  
       2022-07-26 08:57:14 +08:00 via iPhone
    不要加密压缩,用常规的加密,加密之后,文件内容看起来就是随机,
    理论上本地数据,云端数据,一起坏的概率,很低
    catsoul
        24
    catsoul  
       2022-07-26 09:16:04 +08:00
    @bigdoing OP 意思就是有的沙雕网盘会直接爆杀所有加密文件,所以直接 pass 了网盘方案
    mxT52CRuqR6o5
        25
    mxT52CRuqR6o5  
       2022-07-26 09:29:08 +08:00 via Android
    @kerrspace 群晖有 12 盘的型号啊,配上 10T+的硬盘都能组上百 T 的阵列了
    zlowly
        26
    zlowly  
       2022-07-26 09:35:47 +08:00
    压缩包都有 CRC 校验的,里面的数据损坏就会导致部分甚至所有文件无法解压。
    如果是想要快速比较不同目录(硬盘)下数据,可以对所有文件做 HASH ,然后进行 HASH 比较即可。Linux 下有 hashdeep 之类对目录 Hash 的工具。
    luny
        27
    luny  
       2022-07-26 09:40:22 +08:00
    这种是不是考虑增量刻盘备份,成本不是很高
    GrayXu
        28
    GrayXu  
       2022-07-26 09:46:36 +08:00
    第一段就是 RAID1 。MD 也是 raid
    后面抛出了个远古问题,ZFS 很早就解决了。请搜索 zfs scrub 。
    Martin123123
        29
    Martin123123  
       2022-07-26 10:24:03 +08:00
    不太确认 op 的使用场景,对于这种数据损坏的校验一般 nas 提供的解决方案已经足够优秀
    比如群晖的 Hyper Backup 、Snapshot Replication ,RAID -> Snapshot -> Backup 很多时候已经足够保证你文件的安全
    至于容量这块的话,比如我的 1821+自身就有 8 盘位,基本上不太需要拓展,而且如果需要拓展可以考虑使用 DX517 / DX1222 ,如果 8 盘位的情况下都会存在容量不足的情况是否应该考虑一下更换更大容量的硬盘「 16tb ?」毕竟即便是 RAID1 的情况下都有 64TB 的容量,即便存在其他备份盘的场景,正常也不会低于 40tb ,单价 1tb 也是 100 左右,逐步更换更大容量的硬盘可能更合适
    geniussoft
        30
    geniussoft  
       2022-07-26 10:35:40 +08:00
    @kerrspace
    你要搞清楚,群晖不是“故障毁盘”

    DSM 非常敏感,比如数据线上的 CRC 错误,比如接口上的不稳定。
    它只是将不可信的磁盘进行了标记,并没有“毁盘”。
    只是为了拯救你的数据罢了。

    DSM 的逻辑是,你的数据,肯定比磁盘贵一个数量级以上。因此,无条件保全数据的安全。

    ---

    大部分 RAID1 巡检都无法对比数据,请了解。
    另外,企业级机械硬盘,发生位反转的可能性几乎为零。
    tool2d
        31
    tool2d  
       2022-07-26 10:37:24 +08:00
    文件少量损坏是正常的,网上分享文件都是加恢复卷的,这都是血淋淋的教训。

    文件大量损坏是不正常的,一般意味着要直接换硬盘了。

    本来就是离线保存,不用考虑那么多。只要恢复卷能正常工作就可以了。
    hezhile
        32
    hezhile  
       2022-07-26 10:44:18 +08:00   ❤️ 1
    ecc ram + zfs
    libook
        33
    libook  
       2022-07-26 10:44:36 +08:00
    用 md5 之类的 hash 算法算一下两个硬盘里的文件是不是一样。
    但有个问题就是如果不一样的话你不知道是哪个硬盘里坏了,所以最好把算出来的 md5 值存下来,用这个值分别对比两个硬盘上的文件算出来的 md5 值,看哪个不对,就大概率是哪个坏了,这样的话你就至少还有一块硬盘存这个 md5 值。
    但此时另一个问题来了,如果两块盘的文件算出来的 md5 值和你单独存的 md5 值不一样,就得看两块硬盘文件算出来的 md5 值是不是一样,如果一样就说明大概率你存 md5 值的那个盘坏了,如果也不一样就说明……额,就不知道怎么回事了。

    把上述操作稍微进行一下改进(比如引入奇偶校验)和简化,就差不多是一个叫做 SnapRAID 的软件了,这个软件就是手动运行检查你的数据盘和校验盘,看数据是否损坏,如果损坏了可以手动给个指令进行修复。
    newmlp
        34
    newmlp  
       2022-07-26 10:46:19 +08:00
    可以用纠删码冗余一些数据,可以在有限的数据损坏时进行恢复,比如 Windows 的存储空间,或者 minio 进行数据存储
    leefor2020
        35
    leefor2020  
       2022-07-26 10:46:23 +08:00
    我重要文件一般三份,NAS 上,移动硬盘(这个是加密的版本,防止移动硬盘丢失数据泄露),然后加密后的再备份到 Dropbox
    Greenm
        36
    Greenm  
       2022-07-26 10:51:42 +08:00
    云盘不能只拿国内的云盘举例,也要考虑国外的云服务。

    国外的成熟 SaaS 服务能够做到 6 个 9 甚至更高的可靠性,个人从成本的角度出发很难超过这个值。 将本地的数据用 GPG 加密后上传到国外的网盘服务或者对象存储,如 backblaze ,我觉得是比较合理的方案。
    lslqtz
        37
    lslqtz  
       2022-07-26 10:53:36 +08:00
    唯一的解决方法就是备份,备份手段相对不重要,备份数量和校验重要。
    chevalier
        38
    chevalier  
       2022-07-26 11:27:50 +08:00
    5 块硬盘冷备份,最好存在两个地方,规避火灾水灾等情况
    xiaowu2oi3
        39
    xiaowu2oi3  
       2022-07-26 11:31:55 +08:00
    两地三中心个人可以三个品牌移动硬盘同步数据,然后存放在不同地方,也可以加密网盘再跑一份。
    bigdoing
        40
    bigdoing  
       2022-07-26 11:52:45 +08:00 via iPhone
    @catsoul 云盘可以白嫖,永远不付钱
    既然都要花钱了,加密存 oss ,不是更便宜,简单
    或者存 aliyun ecs 也可以
    leeg810312
        41
    leeg810312  
       2022-07-26 12:41:29 +08:00 via Android
    云平台也只是 3 个备份,sla 是 n 个 9 ,不知道 OP 是要搞什么业务,要 100%?
    kerrspace
        42
    kerrspace  
    OP
       2022-07-26 13:13:22 +08:00
    @leeg810312 一些丢失了再也找不到的文件 譬如说我用爬虫一直在监控很多论坛上对一些社会议题的讨论(譬如说女拳,唐山事件,生育率大跌等等),然后自动保存下来。现在这些原始材料大部分都被冲水、和谐了。所以如果文件丢失或者损坏,根本没办法在其他地方找到。这不是那种存点电影之类替代性强的。
    xyjincan
        43
    xyjincan  
       2022-07-26 13:32:13 +08:00
    操作系统读写文件时硬盘有校验,你可以打包为 zip ,然后计算 sha256 ,保存为 txt ,放在同目录,需要检查时,重新计算 sha256
    tril
        44
    tril  
       2022-07-26 14:04:11 +08:00   ❤️ 1
    对于静默损坏,btrfs 和 zfs 都支持主动报告错误,巡检整个文件系统只需要一行命令,所以判断文件是否有错误不需要你重新想办法做校验。

    至于发现了错误如何修复,r5 和 r6 阵列也可以巡检并自动修复错误的文件。当然,你想让硬盘离线保证安全的话,每次巡检文件系统之后如果发现错误手动替换错误文件也是可以的。
    datoo
        45
    datoo  
       2022-07-26 14:43:45 +08:00
    @kerrspace 你这是国安来钓鱼的吧。。。
    exocell
        46
    exocell  
       2022-07-26 15:47:25 +08:00
    直接备份到网盘就可以了。增量备份,你说的百度删压缩包我从来没遇到。
    在网盘备份了上 TG 的压缩包。特殊符号中文密码 16 位加密。压缩完选择自测试。
    网盘如果要跑路了,挂个机下了换个平台。移动硬盘数据坏了就网盘拉那次增量下来就行
    imsoso
        47
    imsoso  
       2022-07-26 15:58:35 +08:00
    备份、备份的备份、备份的备份的备份😄
    testver
        48
    testver  
       2022-07-26 16:34:44 +08:00
    想太多了,一份 nas ,一份自己 pc 硬盘,一份光盘刻录机刻盘,一般家庭用足够了。
    yvescheung
        49
    yvescheung  
       2022-07-26 17:34:41 +08:00
    @kerrspace 京东威联通自营现在就有 24 盘位的 NAS 卖,你要是还嫌不够,可以联系厂家,只要你有钱,几百个硬盘的阵列他们都能给你做出来
    https://pic3.zhimg.com/v2-a05ad4545324fc1d2f4fb9d3bd1b47aa_1440w.jpg?source=172ae18b
    bigdoing
        50
    bigdoing  
       2022-07-26 17:40:36 +08:00 via iPhone
    @kerrspace 加密存网盘,用强加密,2048 位密码,加密软件,不是 rar 7zip
    懒得搞,就用 oss ,或者阿里云 ecs ,
    维护简单
    spediacn
        51
    spediacn  
       2022-07-26 17:58:11 +08:00
    我也觉得,楼主是在自己造一个 RAID1 ,用一个现成的小号 NAS 就行了,
    非得在安全一点,配置一个异地同步就行了,比如两个地方各自放一个 NAS ,然后 zerotier 组网,配置一下主从和同步策略,扔在那儿他就自己同步了,不需要你操心过程。
    lookStupiToForce
        52
    lookStupiToForce  
       2022-07-26 18:40:59 +08:00
    转存数据作离线冷备份的话
    现在有用蓝光盘作冷备份的,你可以关注一下
    硬盘说是最长才 20 年就消磁,但归档级蓝光盘可以达到 50 年到更长
    https://www.zhihu.com/question/29443987
    opengg
        53
    opengg  
       2022-07-26 20:32:48 +08:00
    加密,恢复卷,上传到 oss 啊,冷存储价格很低。
    BurneJones
        54
    BurneJones  
       2022-07-26 21:37:58 +08:00
    加密后上传到 GoogleDrive/onedrive/dropbox/blackbaze/mega/pcloud/box/yandex cloud/Ali/baidu/teracloud 等等各家网络存储放一份。。。
    nVic
        55
    nVic  
       2022-07-26 22:09:08 +08:00
    其实你的担忧有道理,我有一个合作的承包商在做**堡项目,这个项目在网上很容易搜到,总价很高,项目就包含了超大规模冷备,单数据量在 100P 以上,涉及到一些混合存储技术,包括磁带和 bd ,确保数据在极端情况下能够保存至少 100 年的概率超过 6 个 9.
    hcocoa
        56
    hcocoa  
       2022-07-26 22:32:09 +08:00
    不要问 XY Problem: https://coolshell.cn/articles/10804.html

    你其实想知道的是如何保证高可用性,试试 BackBlaze B2 吧( 20 元一条,发之前删掉括号)
    scegg
        57
    scegg  
       2022-07-26 22:36:27 +08:00
    大量的损坏就发生在读取的过程中。也正是因为如此,存储系统不会经常的去靠读取数据来检测数据是否损坏,而是考虑当数据使用时候发现损坏如何补救。
    hs0000t
        58
    hs0000t  
       2022-07-26 22:43:41 +08:00 via Android
    首先,关于磁盘静默错误,已经有了多种解决方案,我目前在用的是 snapraid ,可以参考这个视频来配置。我目前的配置和这个视频里一致,每天检查 8%的数据,自动进行修复。
    https://b23.tv/BV1vU4y1q7cS
    此外,如果担心软件在运行的时候,内存发生位反转,可以使用 ecc 内存,不过这个的概率还是比较小的,除非是使用环境有辐射源,如医院 安检等,普通家用基本不用担心这个问题
    hugee
        59
    hugee  
       2022-07-27 15:36:38 +08:00
    在非地震带建一个恒温恒压真空室,把移动硬盘放进去。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2717 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 09:24 · PVG 17:24 · LAX 01:24 · JFK 04:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.