KDE、レポジトリを失いかける 58
ストーリー by reo
おおこわいこわい 部門より
おおこわいこわい 部門より
ある Anonymous Coward 曰く、
今月 22 日、git.kde.org をホストしていた仮想マシンの障害により。たまたまリブートしていた 1 台を除く全てのリポジトリが消失したらしい (Me, my blog, and my Johnson の記事、本の虫の記事より) 。
セキュリティアップデートのためサーバー本体を再起動した際に git.kde.org をホストしていた仮想マシンのファイルシステムが破損してしまい、git.kde.org の復帰後そのままミラーサーバーに適用されてしまったという事らしい。仮想マシンのシャットダウン自体は特に問題なく行われ、破損の原因は不明。ファイルシステムのエラーの蓄積が原因の可能性もあるとのこと。ミラーリングシステムは約 20 分毎に同期を行うようになっており、git.kde.org の復帰後、程なくミラーサーバは破損したプロジェクトファイルを取得、それローカルに適用したことで、結果的に全てのミラーサーバのリポジトリが消失してしまった。
幸運にも、前日に projects.kde.org のシステムの移行のために立ち上げられた 1 台のサーバが、ミラーリングする予定の時間にリブートされており同期が行われなず、このサーバに完全なリポジトリが保存されていたため復旧することが出来たとのこと。
ミラーリングはバックアップじゃね～よ (スコア:5, すばらしい洞察)
と思うのは少数派なんだろうか
Re:ミラーリングはバックアップじゃね～よ (スコア:5, 興味深い)
少なくとも、「単にミラーしてたから安心」と思っていた訳じゃなくて
と一応の対策はしていた訳です(それをバックアップだとも言っていない)。
それでは、耐障害性が足りず、今回の問題につながってしまったと。
ファーストサーバーもこんな感じだったのかな。
Re:ミラーリングはバックアップじゃね～よ (スコア:2)
テープも一世代しか残さなければ同じなんだが
みんなわかってくれないorz
#バックアップの最低用件は取得したデータが正しいこと
バックアップとリダンダンシー (スコア:2)
2ちゃんのなれる！SEスレ見てても思ったのだけど。
ネットワーク屋の言うバックアップは、待機系という意味なんだよね。
で、ストレージ屋が待機系と言ったら、それはリダンダンシーであって
バックアップではないと。そこを判って欲しいんだよなあ。
失うと大変なデータはテープ、光学メディア、この際USBメモリでもいいから、
別メディアに「バックアップ」してもらいたいものです。
Re:バックアップとリダンダンシー (スコア:2)
ネットワークだろうがストレージだろうが両方ありえますよ
Re:ミラーリングはバックアップじゃね～よ (スコア:1)
どうして、こんな設定になったのだろう。
ちなみに、ちゃんと外付けのHDDもあって、そっちにも、おなくなりになる１年ほど前の状態はバックアップされていたという不思議。
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
Re:ミラーリングはバックアップじゃね～よ (スコア:1)
と思うのは少数派なんだろうか
おそらく少数派じゃない? ミラーリングは物理的破壊に対するバックアップだから。
Re:ミラーリングはバックアップじゃね～よ (スコア:2)
俺もそう思う
バックアップという言葉が示すものは、対象とレイヤによって意味するものが違う。
サーバ機のＨＷ障害に対するバックアップ対策として、別のサーバ機にデータをミラーリングするのは正しい。
今回のＫＤＥの問題は、ファイルシステム破損への対策がなかったこと。
それに対して、世代バックアップも条件を満たせば解決策になるかもしれないけど、ミラーリングの前にデータの完全性を確認することでも対策としては正しい。
逆に障害を想定し、それに対策したわけではないなら、何をやってもバックアップにはならない。
テープに落とせばバックアップになる、と安易に思ってるのも困り者。
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
確かに。
「何でバックアップが無かったの？」
「ミラーリングしてるから大丈夫だと思った」
は、もう聞き飽きた。
Re: (スコア:0)
この場合のミラーリングってRAIDのことじゃなくて、負荷分散のためのミラーリングじゃないの？
#バックアップくらい別に用意しとけよな
Re:ミラーリングはバックアップじゃね～よ (スコア:2, 参考になる)
どうしてこうもリンク先すら読まない馬鹿ばかりなのか
> (追記)
> 以下のテキストは公開時より書き換えられてはいないが、我々のバックアップ方法や失敗原因などの詳細に関する疑問に答えるために追記した。もし以前にこの記事を読んで、「おい、なんでバックアップ取ってねーんだ」と思ったならば、追記を読むといい。
> 当初公開した記事で説明し忘れたことがある。我々はレポジトリのtarballは持っている。tarballは数日おきに作成しているが、これは完璧なバックアップというわけではない。より詳しくは記事中で説明する。
実例 (スコア:3, 参考になる)
ミラーリングはバックアップじゃないという実例ですね。
分かっていても時間や予算の関係でバックアップが取れない場合も。
数百～1000台あるVMware Viewのデータストア(数十TB)とか。
# サーバグレードじゃなくていいので作業前くらいSATAの安いHDDに取らせて貰えないかな……。
Re: (スコア:0)
時間と金をかけらんないからバックアップしない、
ってのがよいケースもあるでしょう。
あなたの環境や、KDEがどうなのかは知りませんが。
別のコメントにもあるように、コピーを持ってる個人は
山ほどいるわけだから最悪それでいいやとかいう方針
だった可能性もあるのかな。
うちに (スコア:3)
10日前のミラーがある
多分、同様の人は探せばいくらでもいると思うが、、
山ほど開発している人がいるわけで。
Re:うちに (スコア:2, すばらしい洞察)
ミラーは山ほどあるだろうけど、ファイルの正統性を確認するのが大変そう。
#異なるデータがあったときは多数決？
Re: (スコア:0)
そこだよなぁ
毒入れされてないことを絶対的にどう保障する気なんだかと
Re: (スコア:0)
どこかの安定バージョンのアーカイブではハッシュ取ってるだろうから、
そこからの差分でちまちま検証するしかないか。
Re: (スコア:0)
他のものなら大問題になっただろうけど、ソースコードはgit/hgなどのバージョン管理ソフトを使っていれば、「ダウンロードした状態」に戻すのは簡単じゃないかな。
Re: (スコア:0)
gitなんだからすべてのコミットには自動的にハッシュがついてるよ。P=NPを証明でもしない限り破るのは不可能。
Re:うちに (スコア:2)
そりゃまあ、何処かの誰かが最近の完全コピーを持っている可能性は高かったと思うけど、
公式にバックアップがなかったことが問題なのでは。
Re:うちに (スコア:4, 参考になる)
リンク先にも書いてあるけど、公式にバックアップはあったよ。
消失しかけたのは、問題が起きる直前のレポジトリ、常に多数の開発者によって変更が加えられるから。
定期的なバックアップに差し替えるのはかなり手間がかかるって話。
Re:うちに (スコア:1)
ああ、なるほど。理解しました。
Re: (スコア:0)
最近のバージョンだけならともかく、100日前のミラー、101日前のミラー、…と
リポジトリを復旧できるほど「いくらでもいる」とは思えません。
Re: (スコア:0)
普通に分散バージョン管理システムを使ってたら、最新のバージョンだけじゃなくて過去の履歴も含めてローカルにコピーされてると思うのだけど。
バックアップの話をする前に読もう (スコア:3, 参考になる)
http://jefferai.org/2013/03/24/screw-the-mirrors/ [jefferai.org]
・不完全ではあるがバックアップはあった
・リソースが少ないのでバックアップへどこまで投資すべきか
・30日分900Gが必要？ZFSのスナップショットでいく？
Re:バックアップの話をする前に読もう (スコア:2, 参考になる)
そうそう。重要な情報を追加。
ファイルシステムの破損は2/22から始まっていたらしい。
だから最低30日程度は前のバックアップが必要になるねって話。
＃セキュリティアップデートなかったらと考えると90日2.7Tくらいはほしいところなのかな。
Re:バックアップの話をする前に読もう (スコア:1)
なんか聞いたことあるような話と思ったらこれだった。
GNUのレポジトリ・サーバー、クラッシュ [srad.jp]
Re: (スコア:0)
実際バックアップを設計するとなると、30日間、90日間を等間隔（毎日）で保管するよりは、
直近二週間は毎日、あとは毎週に間引いて保存、という形にするだろうね。
そして古いバックアップはホットにスタンバイさせておく必要もない。
Re: (スコア:0)
ZFS……NexentaStorがアップをはじめましたね。
Solarisは、KDEを歓迎します(^o^)？
今年もお引越しの季節がやってまいりました (スコア:0)
KDEもQt同様Gitoriousに移転しよう。
部門名 (スコア:0)
怖いもの見たさで喪失後の慌てぶりや対応ぶりを見てみたい気もする･･･
# ｢～障害により。たまたま～｣ なんすかこれ？
自動だけでなく (スコア:0)
手動でバックアップをとるのも大切なのね
Re: (スコア:0)
というより、「ただのミラーリングはバックアップたり得ない」ということかと。
Re: (スコア:0)
オフサイトコピーとスナップショットを取れ
建設的に行こう (スコア:0)
もって他山の石とせよ。
というわけで、みなさんの知っているバックアップの要件を教えてください。「こんな工夫をしていた」というアイディアなんかも。
Re:建設的に行こう (スコア:4, おもしろおかしい)
書類.xls
書類.xls.bak
書類_バックアップ.xls
★書類最新版.xls
書類(レビュー待ち).xls
書類_sav.xls
本当の最新版_書類.xls
Re: (スコア:0)
zip最強
Re:建設的に行こう (スコア:3, おもしろおかしい)
最終版.zip
納品版.zip
完全版.zip
Re: (スコア:0)
それだとソートできない。{prefix}{date}{option}.zipでファイナルアンサー
Re: (スコア:0)
古今和歌集
続古今和歌集
新続古今和歌集
昔の日本人も考えることは一緒か
Re: (スコア:0)
納品版よりタイムスタンプが新しいものがあると血の気が引きますな。
特に「最新」とかの名前が付いてると。
これ、githubにもミラーしてたら… (スコア:0)
まだなんとかなったんじゃないか、というのは素人考えかな？
ミラーリングと違って、壊れた状態のデータをgit pushなんてできないから。
Re:これ、githubにもミラーしてたら… (スコア:1)
pushとcloneとmirrorオプションの有無の違いをplease.
「clone --mirror」と「push --mirror」は何が違うの？
Re:これ、githubにもミラーしてたら… (スコア:1)
git使って同期しても壊せるよ。
push --mirrorで壊れたリポジトリを送りつけたらpushされた方はリポジトリとしては壊れてなくても内容は壊れる。
# gcする前だったら各ブランチのHEADのID使って救えるかもしれないし、push --allで同期してたら簡単に救えたかも知れず。
Re: (スコア:0)
.gitフォルダが壊れてるから一緒でしょ。zipやtarで定期的にアーカイブするのが最強。DropboxやGoogleドライブで２、３重化もラクラク
Linux使ってればよかったのに (スコア:0)
以前M＄の鯖がクラッシュした時にLinuxを使っていたらこんな事故は起こらなかった。との多数のご指摘がありました。
この組織もLinuxを使っていたらよかったのにね。
Re: (スコア:0)
ext2の頃は頻繁にファイルが消失していたから警戒していたので大きなトラブルがなかった。
ext4になったら心配がなくなったので、緊張感がなくなり、かえってトラブルが増えた。
Re: (スコア:0)
microsoftがHyper-Vでlinuxをサポートしているご時世にそんなこと言われてもな。
ホストサーバーがWindowsである可能性は無いわけでもない。
若さってなんだ (スコア:0)
たまに消えて書きなおしたほうがコードの質が上がる気がするする。
対策ってなんだ 振り向かないことさ
Re: (スコア:0)
リファクタリングの新しい手段としてクラッシュが追加されました。