アカウント名:
パスワード:
と思うのは少数派なんだろうか
少なくとも、「単にミラーしてたから安心」と思っていた訳じゃなくて
バグの原因は設計上の欠陥だ。git.kde.orgは常に信頼できる一次ソースであるという前提。この前提の理由は明白だ。git.kde.orgはしっかりと管理されており、プッシュされたコードはすべて妥当性を検証するよう独自のフックをかましていたのだ。常に正しいと仮定することは妥当な決定だった。そして、ミラーリングシステムは、それほどの時間差なく、git.kde.orgと全く同じように振る舞うべく設定されていた。これはgitレポジトリのコードのみならず、管理上の多くのメタデータまでにも適用される。同期はおよそ20分ごとに発生し、ミラーリングシステムはanongitをgit.kde.orgと全く同じようにみせかけ、一次ソースが死んでいたり交換されたりしたならば、ミラーからレポジトリを同期するように設計されていた。我々は、サーバーがディスクを紛失したり、あるいはサーバー自体が塵になったり、VMのファイルシステムが完全に消失した場合には備えていたものの、ファイルシステムの障害には備えていなかった。この障害の具合が、ミラーリングシステムに予期せぬ問題を引き起こしたのだ。
バグの原因は設計上の欠陥だ。git.kde.orgは常に信頼できる一次ソースであるという前提。この前提の理由は明白だ。git.kde.orgはしっかりと管理されており、プッシュされたコードはすべて妥当性を検証するよう独自のフックをかましていたのだ。常に正しいと仮定することは妥当な決定だった。
そして、ミラーリングシステムは、それほどの時間差なく、git.kde.orgと全く同じように振る舞うべく設定されていた。これはgitレポジトリのコードのみならず、管理上の多くのメタデータまでにも適用される。同期はおよそ20分ごとに発生し、ミラーリングシステムはanongitをgit.kde.orgと全く同じようにみせかけ、一次ソースが死んでいたり交換されたりしたならば、ミラーからレポジトリを同期するように設計されていた。
我々は、サーバーがディスクを紛失したり、あるいはサーバー自体が塵になったり、VMのファイルシステムが完全に消失した場合には備えていたものの、ファイルシステムの障害には備えていなかった。この障害の具合が、ミラーリングシステムに予期せぬ問題を引き起こしたのだ。
と一応の対策はしていた訳です(それをバックアップだとも言っていない)。
それでは、耐障害性が足りず、今回の問題につながってしまったと。
ファーストサーバーもこんな感じだったのかな。
テープも一世代しか残さなければ同じなんだがみんなわかってくれないorz
#バックアップの最低用件は取得したデータが正しいこと
日次バックアップを３世代保管にしておいた。金曜夜の作業ミスでデータが破損したことに気づかないまま月曜に出勤してきて・・・
2ちゃんのなれる！SEスレ見てても思ったのだけど。ネットワーク屋の言うバックアップは、待機系という意味なんだよね。で、ストレージ屋が待機系と言ったら、それはリダンダンシーであってバックアップではないと。そこを判って欲しいんだよなあ。
失うと大変なデータはテープ、光学メディア、この際USBメモリでもいいから、別メディアに「バックアップ」してもらいたいものです。
ネットワークだろうがストレージだろうが両方ありえますよ
VRRPが待機系のことを正式に「バックアップ」とよんでいるから。わかって欲しい、じゃなくてそのことを自分側が理解すべきこと。
RFCの一つに（たった一つに）その意味で「バックアップ」と正式に書いてあったからと言ってそれが何の根拠になるのでしょうか？
ISOだとかの官僚的な所の文書なら、それが官僚的であるがゆえに広い意味での言葉の根拠となり得るかもしれませんが、RFCではその様に文書を使うのは誤用だと思います。
おそらく少数派じゃない? ミラーリングは物理的破壊に対するバックアップだから。
俺もそう思う
バックアップという言葉が示すものは、対象とレイヤによって意味するものが違う。サーバ機のＨＷ障害に対するバックアップ対策として、別のサーバ機にデータをミラーリングするのは正しい。
今回のＫＤＥの問題は、ファイルシステム破損への対策がなかったこと。それに対して、世代バックアップも条件を満たせば解決策になるかもしれないけど、ミラーリングの前にデータの完全性を確認することでも対策としては正しい。逆に障害を想定し、それに対策したわけではないなら、何をやってもバックアップにはならない。テープに落とせばバックアップになる、と安易に思ってるのも困り者。
確かに。「何でバックアップが無かったの？」「ミラーリングしてるから大丈夫だと思った」は、もう聞き飽きた。
この場合のミラーリングってRAIDのことじゃなくて、負荷分散のためのミラーリングじゃないの？
#バックアップくらい別に用意しとけよな
どうしてこうもリンク先すら読まない馬鹿ばかりなのか> (追記)> 以下のテキストは公開時より書き換えられてはいないが、我々のバックアップ方法や失敗原因などの詳細に関する疑問に答えるために追記した。もし以前にこの記事を読んで、「おい、なんでバックアップ取ってねーんだ」と思ったならば、追記を読むといい。> 当初公開した記事で説明し忘れたことがある。我々はレポジトリのtarballは持っている。tarballは数日おきに作成しているが、これは完璧なバックアップというわけではない。より詳しくは記事中で説明する。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
ミラーリングはバックアップじゃね～よ (スコア:5, すばらしい洞察)
と思うのは少数派なんだろうか
Re:ミラーリングはバックアップじゃね～よ (スコア:5, 興味深い)
少なくとも、「単にミラーしてたから安心」と思っていた訳じゃなくて
と一応の対策はしていた訳です(それをバックアップだとも言っていない)。
それでは、耐障害性が足りず、今回の問題につながってしまったと。
ファーストサーバーもこんな感じだったのかな。
Re:ミラーリングはバックアップじゃね～よ (スコア:2)
テープも一世代しか残さなければ同じなんだが
みんなわかってくれないorz
#バックアップの最低用件は取得したデータが正しいこと
Re: (スコア:0)
日次バックアップを３世代保管にしておいた。
金曜夜の作業ミスでデータが破損したことに気づかないまま月曜に出勤してきて・・・
バックアップとリダンダンシー (スコア:2)
2ちゃんのなれる！SEスレ見てても思ったのだけど。
ネットワーク屋の言うバックアップは、待機系という意味なんだよね。
で、ストレージ屋が待機系と言ったら、それはリダンダンシーであって
バックアップではないと。そこを判って欲しいんだよなあ。
失うと大変なデータはテープ、光学メディア、この際USBメモリでもいいから、
別メディアに「バックアップ」してもらいたいものです。
Re:バックアップとリダンダンシー (スコア:2)
ネットワークだろうがストレージだろうが両方ありえますよ
Re: (スコア:0)
VRRPが待機系のことを正式に「バックアップ」とよんでいるから。
わかって欲しい、じゃなくてそのことを自分側が理解すべきこと。
Re: (スコア:0)
RFCの一つに（たった一つに）その意味で「バックアップ」と正式に書いてあったから
と言ってそれが何の根拠になるのでしょうか？
ISOだとかの官僚的な所の文書なら、それが官僚的であるがゆえに広い意味での
言葉の根拠となり得るかもしれませんが、RFCではその様に文書を使うのは
誤用だと思います。
Re:ミラーリングはバックアップじゃね～よ (スコア:1)
どうして、こんな設定になったのだろう。
ちなみに、ちゃんと外付けのHDDもあって、そっちにも、おなくなりになる１年ほど前の状態はバックアップされていたという不思議。
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
Re:ミラーリングはバックアップじゃね～よ (スコア:1)
と思うのは少数派なんだろうか
おそらく少数派じゃない? ミラーリングは物理的破壊に対するバックアップだから。
Re:ミラーリングはバックアップじゃね～よ (スコア:2)
俺もそう思う
バックアップという言葉が示すものは、対象とレイヤによって意味するものが違う。
サーバ機のＨＷ障害に対するバックアップ対策として、別のサーバ機にデータをミラーリングするのは正しい。
今回のＫＤＥの問題は、ファイルシステム破損への対策がなかったこと。
それに対して、世代バックアップも条件を満たせば解決策になるかもしれないけど、ミラーリングの前にデータの完全性を確認することでも対策としては正しい。
逆に障害を想定し、それに対策したわけではないなら、何をやってもバックアップにはならない。
テープに落とせばバックアップになる、と安易に思ってるのも困り者。
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
確かに。
「何でバックアップが無かったの？」
「ミラーリングしてるから大丈夫だと思った」
は、もう聞き飽きた。
Re: (スコア:0)
この場合のミラーリングってRAIDのことじゃなくて、負荷分散のためのミラーリングじゃないの？
#バックアップくらい別に用意しとけよな
Re:ミラーリングはバックアップじゃね～よ (スコア:2, 参考になる)
どうしてこうもリンク先すら読まない馬鹿ばかりなのか
> (追記)
> 以下のテキストは公開時より書き換えられてはいないが、我々のバックアップ方法や失敗原因などの詳細に関する疑問に答えるために追記した。もし以前にこの記事を読んで、「おい、なんでバックアップ取ってねーんだ」と思ったならば、追記を読むといい。
> 当初公開した記事で説明し忘れたことがある。我々はレポジトリのtarballは持っている。tarballは数日おきに作成しているが、これは完璧なバックアップというわけではない。より詳しくは記事中で説明する。