20TB 的数据存储使用了 Raid0 硬盘有坏道了我果然自作孽不可活

V2EX = way to explore

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

现在注册

已注册用户请登录

Distributions

› Ubuntu

› Fedora

› CentOS

中文资源站

› 网易开源镜像站

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

20TB 的数据存储使用了 Raid0 硬盘有坏道了我果然自作孽不可活

XFS 是个好文件系统,问题在于用它的人比如我够蠢.....
果然非专业系统工程师....

这事学到的经验
1. 备份还是要有的,数据在大也需要考虑这个问题
2. 在考虑文件系统的性能时候要自己记住什么文件系统是不是有 meta 等依赖到外部去了
3. 如果选了 XFS,记住定时备份 metadata
4. 如果机器有问题尽量在最小改动的前提下进行数据抢救,不要 R/W 任何数据对硬盘造成二次伤害

完整记录见这里

https://blog.cnlabs.net/4749.html

排版乱将就下看吧

第 1 条附言 · 2016-07-22 03:37:23 +08:00

22/07/2016
在更新下这个悲伤的故事

数据差不多全部存在,不排除未发现的小文件有校验错误.
然后我又干了个蠢事
机房提供了一个 2x120G + 4x6000G 的备份机器
反正不要钱先搞起

我是准备买下来正式使用的考虑安全肯定不能犯同错误是吧我做了个 raid1
然后可用空间就剩 12T 了我老机器的数据 20T 啊 20T 啊 20T 啊
你让我多的 8T 放哪里去?
赶紧下了另外一个机房的 2 台机器是的还是 2 台 1 台 4T 硬盘
我觉得都是 G 口速度应该差不多
测试延时才 20ms 结果 SAMBA 死活不通换 NFS 可以挂在结果悲剧了 10Mb/s
要知道同机房 SAMBA 我备份速度在 900M/s 啊 1G 可以跑满的啊
8T 的数据 10M 速度要猴年马月啊

然后和机房扯其他 2 个员工让买新机器
只有 1 个员工不错
直接又给我部署了一台不要钱的备份机器
直接挂了“好多好多好多”个硬盘做好 Raid5 告诉我好了让我装系统
装的时候看了下存储空间 2x120G + Raid5 以后还显示 25000G 可用

估计是被我搞懵了直接给我弄个 25T 的这样随便你怎么塞应该都够了
..

不说了继续苦逼去备份数据......

Raid0

XFS

作孽

备份

68 条回复 • 2016-09-29 01:48:53 +08:00

Mirana

2016-07-21 00:14:01 +08:00

头像很带感啊

smallpath

2016-07-21 00:19:58 +08:00

为什么当初要用 raid0.....

fcicq

2016-07-21 00:20:39 +08:00

RAID 50 倒是比 RAID 5 要好...

notgod

2016-07-21 00:23:11 +08:00 via iPhone

@smallpath 当时可能考虑省成本的原因
24t 硬盘 raid0
12t 硬盘 raid1

后面基本都 raid1 和有备份

notgod

2016-07-21 00:24:36 +08:00 via iPhone

@fcicq raid1
raid5 不靠谱只是比 raid0 提高 33 而已

raid60 目前来说是最好的方案兼顾了读写速度和存储成本

wander2008

2016-07-21 00:34:56 +08:00 via iPhone

raid0 …

ferock

2016-07-21 00:42:34 +08:00 via Android

还敢只用 raid 0 么

Andy1999

2016-07-21 00:48:51 +08:00

raid0 不是只能给非持久化数据用的吗

ixinshang

2016-07-21 00:54:54 +08:00 via Android

0 勇气

fcicq

2016-07-21 00:59:50 +08:00

@notgod 50 坏 1 块盘的恢复时间比 5 减半. 60 相对于 z2 没有意义.

meteor2013

2016-07-21 01:00:59 +08:00

@notgod

头像好漂亮，我喜欢。

fcicq

2016-07-21 01:01:16 +08:00

改: 50 恢复时间不减半, 但是恢复负载明显低是对的.

wjself

2016-07-21 01:13:54 +08:00 via Android

R0 一時爽，數據火葬場(๑•̀ㅁ•́๑)✧

likuku

2016-07-21 01:26:22 +08:00

从 2003 年开始，自用的 linux 就一直是 xfs ，各种意外断电重启，都安全可靠。

RAID0 还不作备份，只能说作死。

换成带冗余的 ZFS 吧。

likuku

2016-07-21 01:27:43 +08:00

成本...忘记把数据价值 /丢失数据价值造成的损失算进成本里了吧...

xenme

2016-07-21 01:32:50 +08:00 via iPhone

RAID10 路过

gzelvis

2016-07-21 02:33:23 +08:00

20TB 数据用 Raid0? 不值得同情啊楼主，这个教训是要你深刻记住

超过 5TB 的，都一定要上 Raid5 才保险

重要数据还得异地备份

notgod

2016-07-21 02:45:18 +08:00

@wjself ++++++++++++++++++++++++++1
这话很对算抢救回来了已经

@likuku
不是什么有价值的数据,只是不喜欢浪费,很多东西都丢里面了
真正有价值的就 55G 朋友的数据，丢了不好交代

@ixinshang 确实有些

@ferock 不敢 Raid0 但是不 Raid 还是可以的

以我的经验啊我机器比较多
有时候客户会要求便宜,存储大,这种情况只能使用低端公司的产品
这个时候无 Raid 单盘或者 2 盘无 Raid
我也遇到过各种问题, 但是截止目前来说从未出过因硬盘坏了丢数据的问题

单盘的时候我通常会自己写个 bash 每周收集系统运行和硬件设备情况
当中就包括 smartctl 收集的硬盘健康程度
如果到风险值了会提示，也就提前更换了,只是备份一个硬盘的事
反正都 G 口对 G 口一个晚上完事了

这次很大原因是大意了
一般我的设备生命周期都最少保证 3 年上机器和机房说好了要使用三年给我全新的硬盘
这次这个机器我 raid 看来下硬盘有 WD ， WDC ，希捷， SSD 都 intel 和 M 什么的型号
之前没注意这个事加的机器就让机房给统一型号的硬盘

9hills

2016-07-21 08:00:41 +08:00

@notgod Raid5 很靠谱，只要你的硬盘故障检测做的足够好，两块盘同时坏的概率非常非常小

大多数人说 Raid5 不靠谱，是他们从来就不看 S.M.A.R.T. 数据，直到盘挂了才去换，自然都是带病工作，感觉不靠谱

所以说没有不靠谱的系统，只有不靠谱的人

uyhyygyug1234

2016-07-21 08:15:11 +08:00 via Android

楼主，求看一下这篇密码保护：高利润暴利产品研究

xbb7766

2016-07-21 08:21:29 +08:00 via Android

Raid0...
不考虑性能的话 JBOD 也比 r0 靠谱点。。。

lucifer9

2016-07-21 09:07:11 +08:00

raid 几都挡不住不定时备份

loading

2016-07-21 09:07:32 +08:00 via Android

准备跑路吧

kn007

2016-07-21 09:08:52 +08:00

最后的结果还是好的，恭喜

BOYPT

2016-07-21 09:10:15 +08:00

思维问题呗，并不存在“浪费”，只是机会成本不一样。

aksoft

2016-07-21 09:10:18 +08:00

看头像进来的

Tourin

2016-07-21 09:14:27 +08:00

吓得我赶紧备份了下去。

ytmsdy

2016-07-21 09:14:50 +08:00

看了看自己 RAID 0 存储上的 600 多 G 数据感觉略微蛋疼。。。

ji1043

2016-07-21 09:18:23 +08:00

我那 2T 的数据盘已经躺尸扔家里了。。。看都不想去他。。。用了错误的办法恢复。。。你很幸运。。。

fetich

2016-07-21 09:22:53 +08:00

RAID1 并不是少了一半，楼主的方案会有 20TB 用于数据冗余。 RAID10 才是一半一半。

pein

2016-07-21 09:27:47 +08:00

讲道理 raid10 最好安全性效率都有保证就是要多花点钱

ChopinWong

2016-07-21 09:28:28 +08:00

@9hills 而且 raid5 可以设置好几块灾备盘吧我记得

realpg

2016-07-21 09:44:27 +08:00

@ChopinWong
灾备盘并没啥用
我见过太多的阵列损坏不可恢复（当然暴力恢复还是能找出来点东西的），别说 RAID5 ， RAID6 RAID10 甚至四倍 RAID1 都有挂全盘的
大多就像楼上哪位朋友说的，不看磁盘信息，有 raid 就万事大吉了，很多时候一块隐患盘并不影响访问，如果是同批次的盘很可能有相同的隐患，最后集中短时间爆发

BOYPT

2016-07-21 09:47:33 +08:00

另外继续科普 RAID 5 不靠谱：

Raid5 Failure 并不都是因为磁盘故障，而是因为磁盘设计上有一个统计学上的 URE (unrecoverable read error)失败率，这个失败率只要低于额定值，这个磁盘就是完好的，然而对一个 raid5 阵列，一个读失败则是致命的；

在 raid 5 诞生的年代，这个 URE 概率标准对 100 多 G 的硬盘，这个概率尚可接受，但是随着磁盘容量增加，这个 URE 概率并没有随着而增加，因此对于一个 1T 磁盘，大概 10 多次全盘数据的量就会出现一次 URE 。

likuku

2016-07-21 10:10:05 +08:00

[统一型号的硬盘] 这个风险更大，若某型号盘出了缺陷 /特殊故障，整个盘阵都全完了

“不要把鸡蛋都放在同一个篮子里”

航空业典型例子很多，欧美有过因为某飞机只用一家厂商供应的某种型号发动机，当一次发动机严重故障后，所有使用这种发动机的飞机全部停飞，等待问题被解决。

后来吸取教训，研制新飞机时，要求新机可以兼容至少两家不同厂商的发动机(典型代表空客 A320)

likuku

2016-07-21 10:11:51 +08:00

有条件的就上带冗余的 ZFS 吧，它的一些机制保证了数据(而非磁盘块)可靠性比很多中端所谓“硬件阵列柜”更可靠。

likuku

2016-07-21 10:17:24 +08:00

back blaze 在线存储服务商，他家前几年定期发布他们自己“存储海洋”的硬盘故障报告，可参考：

Hard Drive Reliability Update - Sep 2014 :
https://www.backblaze.com/blog/hard-drive-reliability-update-september-2014/

xcodeghost

2016-07-21 10:37:50 +08:00

我不到 50G 是数据库文件，都直接 raid1 了，敢用 raid0 都是胆大的人

wsy2220

2016-07-21 10:39:55 +08:00 via Android

6 盘 r0 ……

astome

2016-07-21 11:18:13 +08:00

删库跑路

ca1123

2016-07-21 11:26:58 +08:00

上 raid 5 啊坏一块都没关系

ChopinWong

2016-07-21 11:43:46 +08:00

@realpg lol 不定期检查当然是作死... 而且备份很重要啊... 像我们这边, 虽然我觉得有点夸张, 但是他们每天晚上都用磁带增量备份...一周一个快照...

realpg

2016-07-21 11:48:38 +08:00

@ChopinWong
这个超级高敏感数据有必要

其实磁盘挂主要是托管用户，在机房，很多时候阵列报警已经挂一块盘都不知道……
尤其是装 linux 的，很多根本不知道怎么装阵列卡的操作系统层监控程序， DELL 机器的 LED 显示屏拼命报警阵列坏盘，就是没人看得到……

IDC 的运维大多是底层小工，根本不知道显示屏报警是啥，磁盘灯报警是啥

quix

2016-07-21 11:56:16 +08:00

@notgod
备份还是要有的,数据在大也需要考虑这个问题 X
备份是非常重要的, 数据越大越需要 ✓

JerningChan

2016-07-21 15:18:01 +08:00

数据这么重要的东西,都用 raid10 吧?

JerningChan

2016-07-21 15:20:00 +08:00

@gzelvis 为什么不直接用 raid10 呢?
虽然成本是比较高,好像 lz 的 20TB 就要买 40TB 的硬盘了...

qingchn

2016-07-21 15:25:34 +08:00

raid 10

xuhaoyangx

2016-07-21 15:58:41 +08:00

一般都用 ZFS 或者 win 的存储池。

Ixizi

2016-07-21 16:30:32 +08:00

raid 有啥好处，对 SSD 来说

ChopinWong

2016-07-21 19:13:04 +08:00

@realpg 哈哈哈哈，感觉学到了东西。。。没有相关工作经历啊我。。。都是实验室来了什么东西老板丢过来玩的～

cnly1987

2016-07-21 20:00:55 +08:00 via iPhone

@notgod 你是棋子本人？

takashiki

2016-07-21 20:10:11 +08:00

不会是 niupic 的图吧

harborM

2016-07-21 20:17:11 +08:00

为什么感觉这头像很眼熟？

xspoco

2016-07-21 21:43:25 +08:00

@cnly1987 就是他本人。

memorycancel

2016-07-22 02:32:02 +08:00

不明觉厉，围观 lz ，

rtyurtyu

2016-07-22 05:55:47 +08:00

说不用 raid0 那就是根本没有开窍，备份不能基于本地磁盘
磁盘系统永远用最爽的 raid0 ，完全不要考虑备份相关

你的备份方案应该是做到这样：
任意时刻机器消失，你都能完全恢复数据
具体方案自己研究吧

总之 raid1 、 5 、 6 、 10 等等非 raid0 的都是屎，没有使用的理由

rssf

2016-07-22 08:45:29 +08:00

raid5 也不比 raid0 好到哪去，尤其是重 io 负载的话，坏一块接着就是第二块

skylancer

2016-07-22 10:35:44 +08:00

我就不幸灾乐祸的嘲讽卤煮作死了
不过我还是想问问卤煮是用的哪个服务商的服务

notgod

2016-07-22 11:16:13 +08:00

@likuku back blaze 他们开源的那个服务器设计老好了特大存储 :) 的说
我以前准备那他们建模的资源来国内定制一批这种纯粹设备

notgod

2016-07-22 11:18:58 +08:00

@fetich 你怎么算的 2x1000G = 1000G 可用因为 Raid1 是镜像啊不少一半少多少?

notgod

2016-07-22 11:27:15 +08:00

@uyhyygyug1234 我自己都不记得.。。。。。

@BOYPT 正解我看了下各种 Raid 的各种评测有这个事

@ca1123 Raid5 我德国的机器试过这个第一块坏了一般要立刻处理不然其他的很快阵亡后来就对这个无感了

@rssf 同意我遇到过之前德国的机器 3x3T Raid5 就这种情况第一块坏了没注意第二块很快也坏了还好是缓存测试的节点有网络级别的容错不然那次也彻底悲剧

@rtyurtyu 密集型读写还是 Raid0 快,但是数据安全那块基本无解
最接近 Raid0 的就是 Raid60 了美国一个存储 VPS 服务商使用的这个很早以前测试读写速度非常好
正确的姿势应该是 SSD 缓存+SATA Raid0 + 备份

@Ixizi SSD 也有生命周期的, 你 SSD 在多没 Raid1 没容错能力的
Raid 和 SSD 不冲突因为各种企业需求都不一样所以才有各种 Raid 结构和 Raid 阵列卡的的存在

likuku

2016-07-22 12:08:31 +08:00

所以 ZFS （ Mirror,RAIDZ1,RAIDZ2 买不起 NetApp ，那就 ZFS 吧）才是王道啊，
不怕 RAID 卡各家标准不一，不怕 RAID 卡停产，(冗余型存储池)数据读写都有自动校验+自动修复，也可以自己一键下指令校验存储池 /一键修复数据

fetich

2016-07-22 12:34:25 +08:00

@notgod 两个盘组 RAID1 ，毫无疑问其中一个盘为镜像， 50%；但 N 个盘组 RAID1 ， N - 1 盘为镜像，可用容量为一个盘的大小，远远低于 50%。

usernametoolong

2016-07-23 00:40:38 +08:00

兼顾读写安全用 RAID10 。

lcatt

2016-08-05 09:26:56 +08:00

@JerningChan sas 硬盘贵如狗。多 20T 的话要多近 10 万了。。

JerningChan

2016-08-06 00:10:16 +08:00

@lcatt 那你如果沒了數據,100 萬都買不回來的話...
而且也沒必要一次就直接弄多大吧?
應該可以慢慢擴的呀

webjin1

2016-09-29 01:37:41 +08:00 via Android

你可以把没快硬盘单独做 RIAD0 ，等于不做容量也不减小。

webjin1

2016-09-29 01:48:53 +08:00 via Android

@fetich Raid 怎么是 N-1?应该是 N 除以 2

20TB 的数据存储使用了 Raid0 硬盘有坏道了 我果然自作孽不可活

20TB 的数据存储使用了 Raid0 硬盘有坏道了我果然自作孽不可活