[過去ログ] ファイルシステム総合スレ その20 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
914
(1): 06/15(日)17:08 ID:6DNeCkGf(1) AAS
RAIDはアレイが破損したらリビルドかける前に
全データバックアップしろが通説だと思った

バックアップする空きストレージがないとか
そもそもバックアップがないなら
そもそもその運用がおかしい…
(捨ててもいいデータだけとか観て消し録画は除く)
915
(1): 06/15(日)17:27 ID:xQc9M6ba(1/2) AAS
なんでRAIDやりたがるのか意味不明
バックアップの工夫をそれなりにやって
ダウンタイムやデータ損失期間を減らすための最終仕上げだよね
それとも広告であるネット記事を見て導入が大半?
916
(1): 06/15(日)17:35 ID:aJl0W6/T(2/2) AAS
>>913
外部リンク[html]:e-words.jp
外部リンク[html]:www.buffalo.jp
RAIDの文脈で「冗長性」ってのは
RAID構成内に故障したハードウェアが出てもデータの完全性が損なわれない事
「リビルド」ってのはもっぱらその故障したハードウェアを入れ替えて元の冗長性を持つ構成に再構築することを指す
この説明でわかんないんだったら俺にはうまく説明出来ねえ
「リビルドできる冗長性に~」の方がもっと正確な言い回しだったといえばそれはそうなので
わかってて言ってたら単に俺の日本語が下手でごめんだな

>>914-915
本当にクリティカルなデータを扱うなら
定時記録的なオフラインバックアップが常に別にあって
「退避」や「サルベージ」をやる必要すらほぼ無いのが理想だし本当なら当然
もちろん実現にはハードウェアも運用もコストが相応に要るので難しくなるけどね
冗長性が無い状態での改めての読み出しは
結局リビルドとやってる事は似てて当然ながらもし残りのハードウェアが故障すれば(読み出せなくなった分は)完全にパーなんで
これはどちらかというと現実的な次善策

それこそbtrfsならスナップショットとsend/receiveをうまく使えば
オフラインバックアップ用の場所にも高速に増分バックアップ出来るよ
917
(1): 06/15(日)18:37 ID:YrR/Ub7i(1) AAS
btrfsのsnapは呆気ないほど簡単にファイルの先祖返りが長期も短期も可能で、
WinがやっているVolume Shadow Copyの上位互換って印象で、個人的にはとても好き。

でも、バックアップは別途必要かなって思っている。神経質なだけかもだけれど、データって一番大事だから増分・差分だけじゃなく、本体も自分は保持するようにしている。
918
(1): 06/15(日)21:04 ID:YaPsiovj(3/3) AAS
>>916
冗長性ってリビルドのためではなくサービスを止めないためのものでは?
リビルドしなくても冗長性は重要だよ
919: 06/15(日)21:36 ID:xQc9M6ba(2/2) AAS
びっくりしたのはRAIDでリビルド機能が無いと言われたとき
そりゃまぁデータ消えないけどそのまま運用とか狂人だろうに
おーこわいこわい
920: 06/15(日)21:39 ID:nO4JLxoc(1) AAS
>>917
btrfsなら親になるスナップショットを指定して増分モードでsend/receive出来るから
外部にも、
つまり「バックアップ」もスナップショット構造を維持しながら
書き込みは増分だけで済むよって話なんだ

例えばオリジナル上でSnapperで毎日撮ってて06-15→06-16→06-17とかあるとして
同一の06-15が送受信するストレージ上に同時にあれば
それを親に指定して06-16は差分だけ転送で済む
そして06-16が同時にあればそれを親にして06-17は差分だけで……で継ぎ足し出来るわけさ
外部リンク[html]:btrfs.readthedocs.io

>>918
だから「RAIDの文脈で」って前置きして例のURLまで出してるでしょ
「RAIDの文脈で言う『冗長性』は主にはグループのうちn台が故障してもデータの完全性を保ち、そこからリビルドが出来る事」であって
例えば何かしらサーバーとして運用されてる物ならその全体の可用性として
一般的な語句で言う「冗長性」が望ましいというのは事実だしあんたは何も間違ってないけど
それはファイルシステムとデータだけに留まらない話

「たとえリビルドをしなくても全体の冗長性が重要」なんてのはそりゃ当然だけど
ファイルシステム総合スレなんだから
第一にファイルシステムとそれに関連するデータ保存の目的の文脈で話をしてるに決まってるじゃん
921: 06/16(月)02:21 ID:upbk3sl3(1/2) AAS
リビルドは最初からあまり期待しない。
HDDがいかれたときは他のHDDも寿命間近で、リビルド中にお釈迦になった経験がある。

raidを使う利点はコントローラから警告音が盛大に出ることとバックアップの時間が稼げること。

ソフトウェアraidの利点も時間稼ぎかな。
922: 06/16(月)03:30 ID:V26EfEYC(1) AAS
業務用ストレージならスクラブが走るからリビルドあんま失敗しないけどね
最近は別の不具合でボリュームが全損するケースがちらほらある
ストレージも最近高いくせに品質悪いな
923: 06/16(月)05:44 ID:zRTb+SAk(1/2) AAS
RAID1ならリビルドするけどRAID5や6はやらないかなあ
時間かかりすぎるよ
924: 06/16(月)07:30 ID:7sPaAkac(1) AAS
> バックアップの時間が稼げる
これが大事だと思う
925: 06/16(月)07:45 ID:upbk3sl3(2/2) AAS
時間稼ぎだからデータ逃がせる環境ならraid5で十分だよ。
926
(1): 06/16(月)12:57 ID:7WvLU0an(1) AAS
リビルドせずにバックアップ取得
ならRAID不要の環境だし普段からバックアップしとけよ
どれだけ踊らされているのか
927: 06/16(月)16:46 ID:zRTb+SAk(2/2) AAS
>>926
どういうこと?
リアルタイムバックアップしろってこと?
928: 06/17(火)03:11 ID:G5q8UCPD(1/8) AAS
バックアップは毎日取るものでしょ
差分だけなら時間もわずかなので

なんでRAID縮退時にバックアップを取る前提なの?
普段からとってないの?
929: 06/17(火)04:39 ID:Z0BbVoQp(1) AAS
日に一度のバックアップならやっぱりRAID必要やん
なぜそれでRAID不要になるのか
930: 875 06/17(火)09:00 ID:lZRqBMI7(1/4) AAS
「壊れた瞬間に使えなくなる」のか、「まだ使える/処理を継続
できる」のか、はかなり重要なファクターだと思うが?
流石にバックアップあればRAID不要は極論。

ハードウェアRAIDはスクラブやらSMART監視で部分的な故障まで
監視しているからリビルド失敗はない。
失敗した場合でもRAIDカード交換させたら治ったこともあるから
似たようなことがったらカード交換も検討するといいよ。

LVM,ファイルシステム,デバイスドライバーによるソフトウェアRAID
やらフェイクRAIDも「4~5年ごとにハードを買い替える」ことが
守れてば大丈夫だと思うけどねぇ。
931: 06/17(火)09:22 ID:G5q8UCPD(2/8) AAS
優先度について述べているだけ
バックアップを定期的に取らないのにRAID導入しているのが見受けられる
932: 06/17(火)10:22 ID:lZRqBMI7(2/4) AAS
バックアップに対する現場の意識が足りない、という意味で言いたいのは
わからんでもないが、データロストと(RAIDなし環境における)業務/納期
遅延のそれぞれリスクを発生確率を交えて考えると、やはりその意見には
賛同できないよ。
933
(2): 06/17(火)10:29 ID:YcGRWNVI(1/4) AAS
一切の故障がなくてもURE(回復不可能な読み取りエラー)は確率的に起きるのでまず前提が間違ってる
もちろん製品のグレードによりけりで
エンタープライズ用HDDなら限りなく低い確率、具体的には10^15ビットに1回になるぐらいの品質で製造されてるけど
どのHDDにも起き得るし一般的な民生用だと10^14ビットに1回程度で更に確率が上がる

TB単位のストレージでRAID5が現実的じゃないってのは
読み取るサイズが増える分だけURE=リビルド失敗の可能性が高まるから
8TBだと仮定して民生用だと約60%、エンタープライズ用でも約6%ぐらいの確率で失敗する可能性がある

んでRAID1なら片肺でも読み出し出来るし
リトライも容易だけどRAID5じゃそうはいかねー事が多いからな
934
(1): 06/17(火)11:49 ID:fFPZtW+I(1/2) AAS
RAID5,6は理論上の速度や容量効率は利点だけど、
データチャンク、XORパリティで細切れブロック配置したり複雑で
ディスク上のビット単位でのデータ信頼性という意味では
物理ヘッドガチャガチャするHDDではRAID0よりキツそう
(そんなに詳しくないから想像だけど)

実際には様々なレイヤーのパリティやビット訂正で
エラー回復してるんだろうけど、自分が使ってる
RAID1(Btrfs)でさえ3週に1度スクラブかけると
半分ぐらいの確率でエラー訂正しましたのログが残ってるのだわ
935: 06/17(火)12:00 ID:G5q8UCPD(3/8) AAS
URE(回復不可能な読み取りエラー)
というのは媒体mediumエラーでしょ?
HDD/SSDコントローラは生きていて
特定LBA(LogicalBlockAddress)でエラーがでる
局所的ブロック、媒体エラーだよね
HDD/SSD内部でソフトウェア的エラーの可能性はあるけど
カーネルから見たらハードウェアエラー(==故障)だよ
これ範
936: 06/17(火)12:02 ID:G5q8UCPD(4/8) AAS
あとRAID使っているわりには
ファンや電源の冗長化してないよね
これらも故障したら交換するまで停止でしょ
937: 06/17(火)12:12 ID:fFPZtW+I(2/2) AAS
>>933
言われてみればそうだなあ…
HDDだけダウンタイムなしまたは交換時間オンリーを想定してても、
HDDの故障率と比べて電源やファンとかM/B等パーツが
それより壊れないかと言うとうーんって思う…

自分の環境はファンは予備があってすぐ交換できるし、
電源はACアダプターのマザボ運用してるのでちょっとマシ
(ノート用のよくある19VでOK)
938
(1): 06/17(火)12:57 ID:G5q8UCPD(5/8) AAS
>>933
は事実と異なる内容を記述している
あるHDD/SSDでURE(回復不可能な読み取りエラー)が出たら
RAIDレベルによらず全HDD/SSD稼働中なら他のHDD/SSDのデータから復元できる
(要は1台故障と同じ(切り離して故障にするかは別問題でコントローラの設計))
HDD/SSD故障があるのならRAIDレベルによらず多重故障でデータ復元できない
RAID6は2点故障でも復元できるけど
939
(1): 06/17(火)13:27 ID:lZRqBMI7(3/4) AAS
現場的には6%はかなり盛り過ぎだと感じるわ。
RAID のチャンクサイズ考慮して計算されてないか、
スクラブとかSMART監視とかない前提?
940: 06/17(火)13:37 ID:1K0szjjx(1) AAS
>>938
だから「リビルドがUREで失敗する確率は決して低くない」という話だって言ってるじゃん
冗長性のあるRAIDレベルで通常稼働時に単一の障害が訂正出来るのは当たり前じゃねーかw

>>939
あくまで「リビルド中にUREに遭遇する確率」をカタログスペックから単純計算(概算)した数字の話なので
もちろん実際の障害の可能性はもう少し前後し得るよ

改めて補足しとくけどUREはSMARTとかからわかる形で
明確に「故障」せずとも読み取り時に偶発的に起きる確率的現象で
だから市販製品のデータシートにもちゃんと書いてあるんだ(Non-recoverable errors per bits readの項とかその辺り)
もちろん業務用途ならHDD/SSDにしろRAIDカードにしろソフトウェアRAIDにしろ
ずっと上等で堅牢な構成を採用してる事が多いから
破滅的な結果に至る確率はぐっと低いよ
あくまで典型的には個人がRAID5やるシナリオだと致命的になりがちって話ね

外部リンク[pdf]:documents.westerndigital.com
外部リンク[pdf]:www.seagate.com
941: 06/17(火)13:51 ID:G5q8UCPD(6/8) AAS
5分停止したら何億とか会社消滅ならRAIDでサービス継続は分かる

でも個人用途ではHDD故障して機能のバックアップで十分
データ書き戻しで半日くらい止まっても大丈夫
これらが大半
RAID不要だろって話
webや雑誌記事でのせられて使っているだけでしょ?
942: 06/17(火)13:52 ID:G5q8UCPD(7/8) AAS
昨日のバックアップデータで許容ね
943: 06/17(火)14:22 ID:89jEObby(1) AAS
linux板って個人と企業を混合して話をするからエスパー力を必要とされるね
1-
あと 59 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ

ぬこの手 ぬこTOP 0.011s