アカウント名:
パスワード:
容量が大きくなる → クラッシュしたときのダメージが大きくなる
という気しかしない。あと、バックアップはどうするんだろうとか。raid前提か。
RAID1 というか安いのだからミラーすればいいんじゃない?仕事でちょっと買ってみようかな。
プライベートでは、私はその時に買える 2 万円弱くらいの HDD を買い増してバックアップしてます。だいたい二年くらいで壊れるから、二年に一回くらい買って最新の HDD をつける感じ。一番古い HDD を /home にして丸ごと rsync してます。
今回の 18TB が 2 万円を切ってくるのはいつ頃でしょうかね。だいたい 5 千円を切るとその容量の HDD は流通の終わりって感じ。
ミラーはバックアップの代わりにはならない。対処できるのは故障だけで、オペレーションミスやソフトウェアの不具合によるデータロストに対応できない。バックアップとしてのコピーは別途必要。
要らない解説をすると、元コメの、
> あと、バックアップはどうするんだろうとか。
がそもそも余計で、バックアップは保存されているデータ量に比例した量の外部ストレージが要るだけで、HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
そして、「RAID1+バックアップで運用してます」というコメントに対して、「RAIDとバックアップは違うんだよー、知らなかったのー」と「みんなが知らない凄い知識」を披露したくて機会を狙い続けてた人がフライングで噛み付いてる。
HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
はは。これは無いわ。差分データが十分に小さかったらその通りだけど、許容できる時間内にバックアップできて、許容できる時間内にリストアできるように設計する必要があるよ。
ハードディスク1台丸ごとバックアップ・リストアするという戦略は考慮に入れなくても良いのでは?
まともに、RAID+バックアップの構成を取っているなら、HDDの故障時にしなきゃならないのはRAIDの再構築であって、バックアップからのリストアは発生しない。バックアップに頼るのは、何かの操作をミスったかRAIDで吸収しきれない台数のHDDが一度に故障した場合。
「うっかりフォーマットしてしまった」というトンデモ級のミスか、HDDの故障連発か、とにかく「HDD丸ごとバックアップから復旧させざるを得ない事態」がそれなりに起こる想定のシステム設計はおかしい。洪水やら地震やらと同じ、その規模の大災害が起こったら数日営業を停止して復旧作業に当たるレベルの異常事態。避けようがない自然災害と違って、まずは避けられるように設計するのが筋で、起こる可能性を0には出来ないまでも「それでも起こってしまったら諦めて仕事を一時停止」を考慮に入れても組織が潰れないぐらいに設計すべき。
現場はごちゃごちゃしていてそこまで理想的には行かないんだよ! という嘆きがあるのかも知れないけど、「この革新的な新製品はうちの錯乱した現場では使えないよ!」というのは、まあ、「じゃあ旧来の使えそうなやつを使っとけ(笑)」とツッコミを入れざるを得ない。
バックアップからのリストアが必要になるのは故障時だけじゃなくて、ソフト的なデータロス時もありますけど。それは業務プロセスからくるものであってストレージ設計では完全に吸収できない。うっかりフォーマットのオペミス、システム更新後の不具合、通信先から化けたデータが転送されていたなど運用時に起こるトラブルはたくさんあるのに、HDDの故障だけに注目しても可用性は上がらない。
昔から言われてるRAIDはバックアップじゃないという言葉をもう一度読み返してほしい。RAIDは稼働率を上げる一要素にすぎないから。
オペレーションミスでプライマリとバックアップを両方とも削除した場合でもバックアップからレストアできるのでしょうか。なぜバックアップじにオペレーションミスが発生しないという前提が成り立つのでしょうか。
そりゃ、そういう複合事象が発生しないとはいっていない。もちろんそういうオペレーションミスもあるが、同時に起きなければ稼働率は高く保てる。
いいかな、「現在オンラインのストレージ(=プライマリ)をデータロスする」と、あなたの言う「バックアップまで含めてデータロスする」は別の事象だよ。この2つがいつも一緒に起きるならともかく。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
嫌な予感しかしない (スコア:0)
容量が大きくなる → クラッシュしたときのダメージが大きくなる
という気しかしない。
あと、バックアップはどうするんだろうとか。raid前提か。
Re: (スコア:1)
RAID1 というか安いのだからミラーすればいいんじゃない?
仕事でちょっと買ってみようかな。
プライベートでは、私はその時に買える 2 万円弱くらいの HDD を買い増してバックアップしてます。
だいたい二年くらいで壊れるから、二年に一回くらい買って最新の HDD をつける感じ。
一番古い HDD を /home にして丸ごと rsync してます。
今回の 18TB が 2 万円を切ってくるのはいつ頃でしょうかね。
だいたい 5 千円を切るとその容量の HDD は流通の終わりって感じ。
Re: (スコア:0)
ミラーはバックアップの代わりにはならない。
対処できるのは故障だけで、オペレーションミスやソフトウェアの不具合によるデータロストに対応できない。
バックアップとしてのコピーは別途必要。
Re: (スコア:0)
要らない解説をすると、元コメの、
> あと、バックアップはどうするんだろうとか。
がそもそも余計で、バックアップは保存されているデータ量に比例した量の外部ストレージが要るだけで、
HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
そして、「RAID1+バックアップで運用してます」というコメントに対して、
「RAIDとバックアップは違うんだよー、知らなかったのー」と
「みんなが知らない凄い知識」を披露したくて機会を狙い続けてた人がフライングで噛み付いてる。
Re: (スコア:0)
HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
はは。これは無いわ。
差分データが十分に小さかったらその通りだけど、許容できる時間内にバックアップできて、許容できる時間内にリストアできるように設計する必要があるよ。
Re:嫌な予感しかしない (スコア:0)
ハードディスク1台丸ごとバックアップ・リストアするという戦略は考慮に入れなくても良いのでは?
まともに、RAID+バックアップの構成を取っているなら、
HDDの故障時にしなきゃならないのはRAIDの再構築であって、バックアップからのリストアは発生しない。
バックアップに頼るのは、何かの操作をミスったかRAIDで吸収しきれない台数のHDDが一度に故障した場合。
「うっかりフォーマットしてしまった」というトンデモ級のミスか、HDDの故障連発か、
とにかく「HDD丸ごとバックアップから復旧させざるを得ない事態」がそれなりに起こる想定のシステム設計はおかしい。
洪水やら地震やらと同じ、その規模の大災害が起こったら数日営業を停止して復旧作業に当たるレベルの異常事態。
避けようがない自然災害と違って、まずは避けられるように設計するのが筋で、起こる可能性を0には出来ないまでも
「それでも起こってしまったら諦めて仕事を一時停止」を考慮に入れても組織が潰れないぐらいに設計すべき。
現場はごちゃごちゃしていてそこまで理想的には行かないんだよ! という嘆きがあるのかも知れないけど、
「この革新的な新製品はうちの錯乱した現場では使えないよ!」というのは、
まあ、「じゃあ旧来の使えそうなやつを使っとけ(笑)」とツッコミを入れざるを得ない。
Re: (スコア:0)
バックアップからのリストアが必要になるのは故障時だけじゃなくて、ソフト的なデータロス時もありますけど。
それは業務プロセスからくるものであってストレージ設計では完全に吸収できない。
うっかりフォーマットのオペミス、システム更新後の不具合、通信先から化けたデータが転送されていたなど運用時に起こるトラブルはたくさんあるのに、HDDの故障だけに注目しても可用性は上がらない。
昔から言われてるRAIDはバックアップじゃないという言葉をもう一度読み返してほしい。
RAIDは稼働率を上げる一要素にすぎないから。
Re: (スコア:0)
オペレーションミスでプライマリとバックアップを両方とも削除した場合でもバックアップからレストアできるのでしょうか。
なぜバックアップじにオペレーションミスが発生しないという前提が成り立つのでしょうか。
Re: (スコア:0)
そりゃ、そういう複合事象が発生しないとはいっていない。
もちろんそういうオペレーションミスもあるが、同時に起きなければ稼働率は高く保てる。
いいかな、「現在オンラインのストレージ(=プライマリ)をデータロスする」と、あなたの言う「バックアップまで含めてデータロスする」は別の事象だよ。
この2つがいつも一緒に起きるならともかく。