这是一个创建于 2245 天前的主题，其中的信息可能已经有所发展或是发生改变。
存放一些搜集来的东西，会使用，不是收藏。最好相对安全，搜集比较花时间 阵列卡是 H730P
 | 1 mhycy 2019-09-01 23:10:13 +08:00 RAID6，缓存开好，这方案性能并不差，别选择 RAID50 |
 | 2 msg7086 2019-09-01 23:16:28 +08:00 via Android 6 或者 z2 或者 z3。上 50 是作大死。做好备份。 |
 | 5 Enya 2019-09-01 23:26:23 +08:00 via iPhone 好奇，不懂就问，12 块盘 Raid6 性能会不会很一般？ 有没有什么网上的类似测评结果参考一下～ |
 | 7 devlnt OP |
| 8 mhycy 2019-09-01 23:32:28 +08:00 |
| 9 mhycy 2019-09-01 23:33:28 +08:00 |
| 10 mhycy 2019-09-01 23:38:25 +08:00 @devlnt 补充，其实你那篇文章是有问题的 讨论 RAID5 不可靠不仅仅是说第二块盘损坏的可能性，还有数据无法正确读出的概率。。。 PS. 另，亲身经历过 RAID6 双盘损坏，火速购买新盘上线，那个阵列是 146GB*6 |
| 11 devlnt OP @mhycy 这是 raid50..下面是四个三盘 raid5 组成，重建率按照那篇文章的话高于 86.6%?附带三盘四盘不死的概率 |
| 13 devlnt OP @mhycy 86.6%出自知乎那个地址，URE 或者官方说法是 Nonrecoverable Read Errors per Bits Read 是 1 sector per 10E15，代入知乎那个表格，找到单盘 6T，知乎用的是 4 盘，得出数据是 86.6%，我的情况算 3 盘应该比 86.6%还高一点 |
| 14 msg7086 2019-09-02 00:08:57 +08:00  1 @devlnt 四个三盘 RAID 5 做 0 简直是吃饱了撑的，用最低的效率和最高的风险来组阵列，谁想出来的应该直接打死。 至于为什么 RAID 5 不行，你这篇文章里根本就没有提到。 RAID 5 不行的原因是： 当一块硬盘损坏，重建阵列的时候， 你有特别高的概率， 丢掉第二块盘。 http://www.raid-failure.com/raid5-failure.aspx 三盘 RAID 5 的 6T，按照家用级的指标来算，成功恢复阵列的概率只有 23.7%。 换句话说，有 76.3%的情况下，第二块盘在重建的时候无法读出可靠的数据，炸掉整个阵列，丢掉 48T 的数据。 横向比较 RAIDZ3，做 12 盘 3 盘校验，你可以得到 54T 的可用空间，和同时损毁任意 3 块硬盘下仍然不丢失大部分数据的能力。通常情况下当你替换一块坏硬盘并重建的时候，因为 URE 而导致阵列爆炸的情况已经无限接近于 0 了。我司自己的 Z3 阵列前后坏过四五块硬盘了，现在依然 24x7 稳定跑着。 |
| 15 mhycy 2019-09-02 00:13:15 +08:00 @devlnt 重新说明一遍 关注的是 单数据块读取异常导致的不可恢复可能性 RAID50 架构是 先 RAID5 再 RAID0，意味着只要出现一块掉盘且组中出现不可读取数据块异常 那么这一整个 RAID5 组即为数据可不可用组，在 RAID0 情况下....（还用说 RAID0 么？） |
| 17 msg7086 2019-09-02 00:15:34 +08:00 如果你要买质量很好的硬盘（也就是你说的 10E15 的盘，比如昂贵的 WD Red Pro ），那是有 87%的几率恢复数据。不过别忘记，这是「每一次事故」下的概率。如果一年内坏 2 块硬盘，成功率就只有 74%了。5 年的时间内如果累计坏了 6 块盘，最后存活率就只有 40%。 反正我宁愿花 160 刀去买便宜的 10T 硬盘然后选一个 99%可靠程度的方案，也不会去花 210 刀买昂贵的 6T 硬盘然后用 87%可靠程度的方案的。 |
| 18 devlnt OP @mhycy 我说的就是单数据块读取异常导致的不可恢复可能性（ Nonrecoverable Read Errors per Bits Read ）啊 |
| 19 msg7086 2019-09-02 00:23:32 +08:00 @Enya R6 之流速度慢是肯定的，所以缓存一定一定要做好。带电池和超大缓存的 RAID 卡，或者是自带写缓冲的 SSD 等等，Cachecade，或者考虑 ZFS RAID 方案。 我司 L5630 的服务器跑 12 盘 Z3 读写基本在 400-500MB/s 量级，和 10 比性能应该是比不过的，但是也不算太慢吧，而且成本低。 |
| 21 devlnt OP @msg7086 如果是 10E14 的话，大容量的不是重建一次死一次么。。完全不存在 99%的说法啊。。而且真要安全是靠备份的吧。。 |
| 22 mhycy 2019-09-02 00:35:08 +08:00 |
 | 23 annoy1309 2019-09-02 00:39:45 +08:00 认真觉得，你应该把数据按级别分类，我也大概有 20T 级别的数据，按重要级别映射了几个不同的虚拟磁盘，最重要的是 4 块 3T 盘做的 raid1，我觉得不能承受任何代价丢失的数据都在上面，剩余的是大概 8 块 4t 还是 9 块 4t 做的 raid6，放日常数据，最后就是三块 1t 做的 raid0，做日常迅雷啊，游戏啊反正丢了顶多重新下的东西都塞在里面 |
| 24 annoy1309 2019-09-02 00:40:37 +08:00 raid1 做了 4 块盘，我觉得 4 块同时炸掉的可能性还是比较小的，要是真 4 块同炸，说明天要亡我，我认了 |
| 25 devlnt OP @annoy1309 分类了。。稍微重要的全扔 16 盘的 ssd 去了 R10。问题只是针对那些花时间搜集来的数据，没了还是可以搜集=_=只是花时间，很长时间而已。。。 |
| 26 devlnt OP |
 | 27 totoro625 2019-09-02 00:53:57 +08:00 via Android 有一个 raid5 重构成功率计算器 https://raid-failure.eth6.org/ 12 块 6T raid5 也就 0.5%几率重构 |
| 29 Enya 2019-09-02 01:01:07 +08:00 via iPhone @devlnt 我觉得吧，既然上 raid 了，如果有个 500MB/s 我觉得是够的，所以安全性在这个情况下会更重要一些吧，毕竟出问题的时候恢复起来的影响业务的时间也是要考虑的 |
| 33 msg7086 2019-09-02 01:10:01 +08:00 @devlnt #33 RAID 5 重建的时候没有冗余盘，读错一个字节就相当于阵列报废了。 RAID 6 重建的时候有冗余，所以需要同一个字节在两块盘上同时读错才会报废。 你仔细想想，一块硬盘上任意一个字节坏的概率，和两块硬盘上同一个位置的字节同时坏的概率，差多少？ 差 10 个数量级都不止了吧。直接就可以把可靠性拉到 99.99999%以上了。 然后我用的 Z3，坏一块盘以后需要另外三块盘上同一个位置的字节同时坏才会炸，这个概率，是不是无限接近 0%了？ |
| 35 msg7086 2019-09-02 01:14:48 +08:00 你 26 楼还是没想明白，读错不等于挂掉。 读错只是一个块，剩下的 6TB 数据还是好的，还是有效数据。只要这 URE 的这个字节或者扇区有替代品（有其他冗余），就不会炸阵列。你 26 楼是按照整个 6TB 数据全挂来计算的，这个和 URE （单比特、单字节、单扇区损坏）是两回事，你不要搞混了。 「再挂一块，读 10 盘」 应该是再挂一块中的一个扇区，读 10.9999999999 盘，才对。 |
 | 36 ryd994 2019-09-02 01:18:57 +08:00 via Android 你需要的冗余度要和单盘大小成正比。因为单盘是故障单元，而读写速度和单盘容量远不成正比。甚至基本无关。因此重建时间和单盘成正比 @devlnt 不能按企业级标称值计算。且不说标称值只是一个估算，厂家出于自身利益倾向于高估。标称值的前提是恒温无震动电压稳定，也就是什么条件都完美，你问问自己有没有可能做到。而且重建期间是满负荷长时间运转。故障率肯定要比标称值高。 最后，上面纯概率计算成立的前提是两块硬盘的故障事件无关。如果你买的是同一批次或相近批次的盘，而且这些盘同时投入使用。浴缸曲线两个高点。如果是制造有问题，那整个批次都没得跑。如果是正常磨损寿命，那其中一块盘挂的时候，剩下 11 块也活不了多久了。这时候故障率肯定比标称值高得多。 @msg7086 raid6 当然软 raid 啊，为什么用 raid 卡 |
| 39 ryd994 2019-09-02 01:23:58 +08:00 via Android @devlnt 他们说的是数据冷错误。也就是宇宙射线翻转了一个 bit。raid 无法检测和预防这种错误。如果刚好是文件系统的关键 bit，那恭喜了。事实上，别说重建期间，正常运行期间 raid 也无法处理冷错误。raid 设计规范并不指定冷错误时，返回的是哪个盘的数据。一般控制器就是随便取一个。重点：raid5/6 读的时候可以不校验，为了性能。因为 raid 的故障模型是热故障，所以假设只要能读出就是正常数据。 这一点 zfs 吊打同级 raid，缺点是钱要够不然性能太差。 |
 | 40 wangfei324017 2019-09-02 01:24:43 +08:00 raid 5+1 热备 |
| 41 devlnt OP @msg7086 26 楼中挂一块值的是硬盘坏了，再挂一块指的是重建的时候又坏了一块。如果是同一批次，如 36 楼所说，概率不算低 |
| 42 devlnt OP @ryd994 这个估算，我倒是倾向于厂商是低标的。高标对他们自己没好处，被查实虚标吃不了兜着走。恒温跟电压可以做到。。。无震动嘛。。要看你怎么定义震动了 |
| 43 msg7086 2019-09-02 01:48:38 +08:00 @devlnt 全盘损坏的概率是很低的。 一块硬盘要全损，一般三种原因，电路板坏了，磁头坏了，负磁道服务区坏了。 硬盘同时全损的概率很低的，一般说的重建时硬盘挂掉，指的是因为 URE 导致单个扇区读取失败的情况。 大多数硬盘都是从（逻辑）坏道开始的，如果是电路板或者磁头坏，那是生产问题，可能上线跑了两星期就全挂了，再多的 RAID 都解决不了。 另外，URE 本质上并不是「硬件损坏」，或者说并不是「损坏」。磁盘在存放过程中，磁场数据本身就会偶尔改变。换句话说，你一块 6TB 盘放在桌上一年不碰，这 48 万亿比特的数据也会有数万甚至更多，会自己改变，0 变成 1，1 变成 0。硬盘本身有纠错功能，读取的时候，4096 字节里读到了几个字节的坏块也可以原地修复。 这就意味着放置越久的数据，坏比特、坏字节就越多，累计到无法修复的程度时就会产生 URE。 URE 并不意味着什么硬件「坏了」，可能只是「久了」而已。 所以修复这种 URE （逻辑坏道）的方法其实就是全盘擦除一遍，让每个扇区里的坏块都重写成正确数据就行了。 对于 RAID 5 来说，URE 是会由阵列卡自动修复的。（这个我司生产机上已经出现过很多次了，可重现的。） 所以会让 RAID 5 降级的，都是硬盘全损故障。你说重建的时候出现第二块硬盘全损，概率其实是很低的。 上面讨论到现在，都是讨论的第二块、第三块硬盘 URE 的情况。 |
| 44 msg7086 2019-09-02 01:54:04 +08:00 @devlnt #42 这些指标都是理论值，就像 MTBF 一样，都是根据指标进行理论计算得出的，怎么查实？ 比如一块企业级硬盘的标称理论 MTBF 是 150 万小时，你怎么查实？花 170 年去测吗…… |
| 45 ryd994 2019-09-02 01:56:39 +08:00 via Android @devlnt 你怎么证明？这只是一个理想条件下的推算，实际上怎样，厂家也不可能知道。难道新出一块盘就先跑个十年再卖吗？最多高温加速实验，但是加速实验的前提就是假设了加速比例，实际上加速了多少，谁也不知道。很可能是厂家根据各个原价的故障率，理论推算全盘故障率。计算方法不同，得出的数据可以差好几个数量级。 要看实际数据，backblaze 有。真正生产线上跑出来的统计。 |
| 46 ryd994 2019-09-02 01:57:28 +08:00 via Android *更可能是厂家根据各个原件的故障率，理论推算全盘故障率* |
| 47 devlnt OP |
| 48 ryd994 2019-09-02 02:36:48 +08:00 via Android @devlnt 你也知道工信部油耗做不到啊？那怎么 mtbf 就一定能做到？那你应该往高了估还是往低了估？ 一万块一起测？一万块测一小时就等于一万小时的数据？硬盘到寿命末期故障率会迅速上升。混用批次，分批投用，就是为了避免一批一起挂的情况。 你还没考虑人为错误和重建前的人员响应时间。你能做到 24 小时机房有人，长备替换盘么？如果用热备的话你会希望热备随时上线还是错开负载高峰再上线？ |
| 49 msg7086 2019-09-02 02:56:20 +08:00 你开心就好，就用传说中的四组三盘 RAID 50 吧（笑） 你懂得比我们多多了，何必还来问我们这些什么都不懂的人呢（笑） |
| 50 devlnt OP @ryd994 https://www.seagate.com/cn/zh/support/kb/hard-disk-drive-reliability-and-mtbf-afr-174791en/ 希捷的官方文档，很多类似的数据都是经过大量的实体东西去测的原始数据再调整的 |
| 52 devlnt OP |
| 53 ryd994 2019-09-02 03:53:07 +08:00 via Android 3 @devlnt AFR and MTBF are population statistics that are not relevant to individual units. 墨菲定律此处适用，average ≠ maximum 建议换个标题。raid50 牛爆天际，raid6 吃饱了撑的。 你爱用就用，问个 P |
| 55 ryd994 2019-09-02 03:54:38 +08:00 via Android @devlnt Based on the observed error rate over a few weeks or months, the MTBF is estimated and not representative of how long your individual drive, or any individual product, is likely to last. Nor is the MTBF a warranty 建议你好好补习一下英文呢。免得贴个链接打自己脸。 |
| 56 devlnt OP @ryd994 The specification is based on a large (statistically significant) number of drives running continuously at a test site, with data extrapolated according to various known statistical models to yield the results.我的英文大概没有问题 |
| 57 ryd994 2019-09-02 04:04:10 +08:00 via Android |
| 58 devlnt OP @ryd994 它最初是为军事领域开发，可以通过几种不同的方法来计算，每种方法都会产生极为不同的结果。对于硬盘驱动器机构，常见的 MTBF 等级为 300,000 至 1,200,000 小时之间，这可能让人们得出结论，即该规格承诺可实现 30 至 120 年的连续操作。事实并非如此！此规格基于在测试站点上持续运行的大量（具有统计意义）硬盘以及根据各种已知统计模型推断的数据，从而生成结果。 MTBF 是根据几周或几个月内观察到的错误率估算得出，并不代表您的个人硬盘或任何个别产品可以持续使用多长时间。MTBF 也不是质保 - 它代表了一系列产品的相对可靠性。较高的 MTBF 通常仅仅表示该系列机构更加可靠和耐用（取决于所使用的统计模型的一致性）。历史上，包含无论何种原因的所有退货在内，现场 MTBF 通常为预计 MTBF 的 50-60 ％。 明明有官翻还要讨论这种东西 |
| 60 msg7086 2019-09-02 04:15:22 +08:00 4 你爱用就用，问个 P 你开贴之前先告诉大家，推荐 50 以外方案的请勿回帖，这样免得浪费你和大家的时间。 我对这种寻找认同感的帖子实在没什么兴趣，已 Block 以示敬意。 |
 | 61 alphatoad 2019-09-02 05:52:35 +08:00 via iPhone 我从来不做冗余，直接给 raid 0 挂了就拖备份，无所谓 |
 | 62 mason961125 2019-09-02 06:06:22 +08:00 via iPhone 活生生的「对牛弹琴」 |
 | 63 kn007 2019-09-02 07:33:27 +08:00 1 ...做系统集成的，说一句。 其实楼上意见都很中肯，没有什么问题。 实操下来，确实 raid6 很少出问题，而 50。。。呵呵，某机构 7 年连丢两次数据（当然跟不负责运维有关，硬盘坏了都不去看下），都是 raid50。 其实也可以考虑软 raid 就是了 |
 | 64 xenme 2019-09-02 07:38:31 +08:00 via iPhone 看到现在然后去学习了下，发现我的 RAID10 还是很安全的。 另外学习了 URE 的，第一次发现 RAID5 真不靠谱。 即使 3 盘 90%概率的情况下，这概率也不够高啊。 如果每年挂一块的情况下，五年全活概率只有 50%左右。 |
| 65 devlnt OP @kn007 raid6 盘多且大的话重建时间会不会特别长？ raid60 会在重建时间这里好一点么？ 他俩 1，2 楼都点名 r50，就顺着问一下有什么梗，结果就问出事了=_=搞得我跟推销 r50 似的。。。 |
 | 66 lucifer9 2019-09-02 08:08:32 +08:00 raidz2 or raidz3 |
 | 67 Eytoyes 2019-09-02 08:46:46 +08:00 学习了 |
 | 68 7654 2019-09-02 08:48:37 +08:00 不管用不用 raid，用何种 raid，都要做好备份 所以我的 NAS 都是单盘，4 盘位，一份数据备份好几份，重要的实时备份，不重要的每天备份，还带版本控制，总容量利用率介于 raid1 和 5 之间，只要不是同时挂掉两块硬盘，数据永远在线，也不会有超长的重建时间 |
| 69 mhycy 2019-09-02 09:10:41 +08:00 1 早上再看看这贴，发现原来题主不是要问问题是要找认同 爱咋用咋用，线上结果直接告诉你带 RAID5 的阵都不可靠，不信就算。。。 要是钱多直接就上 ZFS 了，而且 ZFS 的最佳实践是 ECC 内存+RAID Z2 以上等级阵列 好好想想这是为什么，另外折腾过存储的都会知道厂商标记的损坏率是多么的不靠谱，别榆木脑袋啥都听不进去 |
 | 70 openbsd 2019-09-02 10:23:36 +08:00 看数据的重要性；既然是松鼠病的数据，直接 RAID 0 就好了 去过两次数据恢复中心，发现做数据恢复的都是 RAID 5 所以生产环境只用 RAID10 + 备份 |
 | 71 Eleutherios 2019-09-02 11:14:23 +08:00 via iPad |
 | 72 itsjoke 2019-09-02 11:16:52 +08:00 之前用 Raid5，渣到后。后面换成 Raid10，性能和可靠性都很不错。 |
 | 73 LiYanHong 2019-09-02 11:22:27 +08:00 买的戴尔服务器，5 块 8T 盘，戴尔给组的 raid5。 |
| 74 Eleutherios 2019-09-02 11:25:19 +08:00 via iPad @LiYanHong 你们真虎啊，8T 盘出现字节反转的概率相当高了，居然敢组 Raid5。我司 600G SAS 盘组建 Raid5 阵列都炸了。 |
 | 75 usernametoolong 2019-09-02 12:55:08 +08:00 12 块盘宁愿组 RAID1 都别去碰 raid5 raid6 以及 raid50 和 raid60, 最保险和性能的方案是组 raid10. |
 | 76 jzphx 2019-09-02 12:57:22 +08:00 raid10 靠谱 |
 | 77 infra 2019-09-02 12:59:45 +08:00 raid6 + 硬件状态监控 |
 | 78 marcushbs 2019-09-02 13:31:32 +08:00 还是看业务逻辑，如果像我就是备份一下照片：分成物理隔绝两组，各自 raid0，然后 rsync 吧 |
 | 79 shutongxinq 2019-09-02 13:37:12 +08:00 其实你这个需求用 zfs raidz1 * 3 也可以，如果实在想用 raid5 类似的结构的话。raidz1 如果只有四个盘还是可以的，这也是 freenas 网站上的推荐设置方法。zfs 会多重备份 metadata，基本没有全盘丢失的可能。 |
 | 80 realpg PRO 自从云火了起来，就开始搞分布式软件定义存储了…… |
| 81 Eleutherios 2019-09-02 14:17:40 +08:00 via iPad @realpg 有点儿贵啊……我感觉我也就用得起 Backblaze B2 / Wasabi S3 这种便宜货 |
| 82 realpg PRO 开源 Ceph 大法好 |
| 83 kn007 2019-09-02 15:38:51 +08:00 @devlnt raid60 讲道理，没实操过，一般就是 6+缓存。 raid6 看你用什么盘，多大，转速怎么样吧，一般都要大半天，正常来说一天内肯定完成。按你的配置可能要超过一天？ 其实不要过于在意重建时间。。。在意的话，raid6 就不合适了。而且 raid6 还吃控制卡。。。 看到说 raid10 的，讲道理 raid10 是比 raid6 更加稳当一点，也不怎么吃控制卡。但可用空间就有点小了。。。感觉血亏，当然你说资料无价的话，那没什么好说的。。。 |
| 84 kn007 2019-09-02 15:43:22 +08:00 在意容错率就 raid6，在意速度就 raid10 不然就考虑软 raid，软 raid 没试验过，不好乱开嘴。 |
| 85 kn007 2019-09-02 15:49:55 +08:00 你可以简单理解成。。。 从容错率来讲，raid50<raid10<raid6 从容量来说，raid50 跟 raid6 差不多，远大于 raid10 从速度来说，raid10 和 raid50 各有千秋，总体差别不算太大，但是肯定比 raid6 好太多。。。 至于 raid5。。。出现问题的几率比 raid50 大于 1 倍有多。 |
| 86 kn007 2019-09-02 16:03:52 +08:00 raid6 出问题，只有 raid50 的千分之一（待考证，忘记在哪看到的了 raid6 出问题，只有 raid10 的 1/250。。。 刚看了楼主需求 “存放一些搜集来的东西，会使用，不是收藏。最好相对安全，搜集比较花时间 阵列卡是 H730P ” 在不考虑软 raid 以及钱的情况下。 如果经常使用，而且占用空间不大，考虑 raid10 吧。可能更适合你。 仅限安全和收藏，偶尔使用，那就 raid6。。。 其实 raid 最重要还是坏盘后，及时更换 |
| 87 kn007 2019-09-02 16:04:31 +08:00 个人工作中浅见，欢迎各位大佬指正。。。 |
 | 88 lsylsy2 2019-09-02 16:05:01 +08:00 @annoy1309 个人觉得 4 盘 RAID1 没必要，他们毕竟在同一个机箱里工作，一个雷劈进来一百块也得一起炸，或者中个病毒一起被格式化 我个人会 2 盘 RAID1，然后另外两块盘做冷备份（每周插上去，备份，拔下来，单周盘 A 双周盘 B ），或者用一块冷备份，另一块的钱买个网盘 /云来加密存到网上。 |
 | 89 autogen 2019-09-02 17:22:53 +08:00 raid10 好，6T 的盘 raid5 重建会失败的 |
 | 90 BaiLinfeng 2019-09-02 21:46:28 +08:00 微信群看到你发的链接了 |
 | 91 zzlzhang 2019-09-02 21:52:39 +08:00 win10 自带存储池吧......真的好用.... 添加减少盘的省事 |
 | 92 Srar 2019-09-03 10:11:02 +08:00 @msg7086 @autogen 中高端 RAID 卡在有热备盘时候都不是全盘进入重建的。而是从坏盘拷数据到热备盘，当遇到坏盘坏道拷不出来时才会从别的盘恢复。等恢复完坏道区继续从坏盘拷数据 https://www.seagate.com/files/staticfiles/docs/pdf/zh-CN/whitepaper/tp620-1-1110cn-reducing-raid-recovery.pdf |
 | 93 ifaii 2019-09-07 16:27:51 +08:00 在用 FC 存储，raid5+1 热备，定时巡检，离线备用盘准备这，也没说得那么可怕，至于 raid0 更安全更快，可是要考虑成本啊 |
 | 94 lc7029 2019-10-07 08:23:01 +08:00 via iPhone raid6 不带 0 |
 | 95 ferock PRO URE 指标很重要 |
 | 96 justaname 2021-09-18 00:05:23 +08:00 @msg7086 我很好奇 RAID5 坏一个字节阵列就废了这种说法到底起源于哪里，有什么依据吗？一个 URE 只会导致最终恢复出来的阵列错了一个 bit，怎么就报废了？ |
| 97 msg7086 2021-09-18 02:54:43 +08:00 via Android @justaname URE 会导致阵列最终数据丢失一个扇区的内容。但是这不是重点，重点是 RAID 需要拿去手动恢复的时候就等于这个阵列报废了。一来系统必须离线然后用软件去恢复，二来恢复出来的数据已经不可靠了。比如你阵列里存着网站的数据库，现在告诉你数据库里有一个扇区的数据是坏的，你怎么想。 |
| 98 justaname 2021-09-29 17:17:26 +08:00 @msg7086 第一个问题的话 URE 并不意味着必须离线然后软件恢复，软 RAID 或者相当部分高级点的硬 RAID 都会跳过或者重映射，第二个问题有一个扇区的数据是坏的这种事情得看场景来决定是否重要吧，如果是多媒体文件的话压根就不怎么所谓，更何况 RAID 也是会定期巡检的。而且这种事情和 raid5 关系也不大，单盘也可能丢扇区呀，解决办法只有备份。大部分否认 raid 安全性的文章主要还是聚焦在很大概率重建会导致整个阵列挂掉，但就我的使用体验来看这个概率相当低，企业也许无法承受（所以会有大量额外的备份），但对个人的数据规模来说相当可以了 |
| 99 msg7086 2021-09-29 17:59:53 +08:00 via Android @justaname 所以要做就做 R6 啊。个人数据我一向推荐单盘+多点备份的。 你说的这个有一个小问题，就是其实你不知道丢掉的几个扇区到底是丢在哪里。如果真丢在了下载的电影里那当然无所谓。要是丢在家庭照片或者重要的文档怎么办，又或者损坏了文件系统怎么办，这些风险总是客观存在的，没有必要去冒这个险。 |
Select Language