■京都大学（2021年12月28日）
2021年12月14日 17時32分 から 2021年12月16日 12時43分にかけて,スーパーコンピュータシステムのストレージをバックアップするプログラム(日本ヒューレット・パッカード合同会社製)の不具合により,スーパーコンピュータシステムの大容量ストレージ(/LARGE0) の一部データを意図せず削除する事故が発生しました.
皆さまに大変なご迷惑をおかけすることになり,深くお詫び申し上げます.
今後,再びこのような事態の生じることのないよう再発防止に取り組む所存ですので,ご理解をいただきますよう,どうぞよろしくお願いいたします.
★ファイル消失の影響範囲
・対象ファイルシステム:/LARGE0
・ファイル削除期間:2021年12月14日 17時32分 ～ 2021年12月16日 12時43分
・消失対象ファイル:2021年12月3日 17時32分以降,更新がなかったファイル
・消失ファイル容量:約 77TB
・消失ファイル数:約 3400万ファイル
・影響グループ数:14グループ (うち,4グループはバックアップによる復元不可)
障害情報:【スパコン】ストレージのデータ消失について
http://www.iimc.kyoto-u.ac.jp/ja/whatsnew/trouble/detail/211216056978.html
★ファイル消失の原因
スーパーコンピュータシステムの納入会社である日本ヒューレット・パッカード合同会社によるバックアッププログラムの機能改修において,不用意なプログラムの修正とその適用手順に問題があったことで,本来は不要になった過去のバックアップログファイルを削除する処理が,/LARGE0 ディレクトリ配下のファイル群を削除してしまう処理として誤動作しました.
日本ヒューレット・パッカード合同会社から提出された報告書を掲載します.
Lustreファイルシステムのファイル消失について (日本ヒューレット・パッカード合同会社)
★今後の取り組み
現在バックアップ処理を停止しておりますが,プログラムの問題を改善し,確実に再発しない対策をした上で1月末までにはバックアップを再開する予定です.
ファイル消失後にバックアップが実行されてしまった領域のファイルの復元ができない状況となったことから,将来的にはこれまでのミラーリングによるバックアップだけでなく,1世代分の増分バックアップを残す等の機能強化を検討いたします.機能面だけでなく,再発防止に向けた運用管理についても改善に取り組みます.
一方で,機器故障や災害等によるファイル消失の可能性も含めて完全な対策は困難であるため,利用者の皆様におかれましても,重要ファイルについては別システムへのバックアップをお願い致します.
※全文は元記事でお願いします
https://www.iimc.kyoto-u.ac.jp/ja/whatsnew/information/detail/211228056999.html
スパコンなんて計算に使う一時的な物しか置いてない
データセンターとは違うのだよ
rm -rf ,/LARGE0
>>6
強制的にフォルダ削除か
>>6
やめてー
>>206
それ出来るのrootの権限持ってる人だろうな
もし本当なら誰なのかは限られてくる
今時こんなミスあるんだな
HP、いつの間にか合同会社に組織変更してたんだ
>>12
そーいやレノボジャパンも合同会社だよな。
株によらない完全子会社だから当然か。
スパコンでも
やってることはログ消す運用スクリプトのrm -rf に渡す引数が間違ってて
親ディレクトリまるごと消えた
みたいな新人SEレベルのミスくさい
こんなことありえるのか？
京大のスパコンはRAIDすら組んでないのか？
>>13
RAIDはストレージの故障を担保するもの
バグありプログラムで消失したデータは無力
>>13
RAIDはアベイラビリティの機能であってデータの保護ではないぞな
今回の場合は普通に消える
使えるグループは限定されるから、容量の割には影響範囲は狭い、クローズされた世界だから備忘録代わりに使っている先生もちらほら、頭の中にだいたい残ってるから
「バックアップを自動的に取る（環境依存でいろいろいじっていらんファイル消したりする）プログラムが誤作動して
ユーザが使う領域にあるファイルを論理的に消してしまった」
ってことなんだろうから、パソコンの大先生が「ぼくのいえのこわれないハードディスク」
講座開いてもどうにもならん
あー、うちの会社でもこの前あったわ
バカがルートディレクトリでrm -rf実行しちゃったんだな
>>36
エリアスでrm -rf /は無効化しとくのがええわな。
スクリプトで rm -rf {変数}/hoge.txtなんて
書いてると必ず事故るし。
>>36
そんなんで消えるシステム自体がおかしい。
核ボタンのスイッチ、間違えて押しちゃいました
みたいな。
>>289
バカの振る舞い迄は防げないよ…
HPの説明書見たら、ほぼ思った通りで草
○ずほ銀行レベルの下請けがやってそう
https://www.iimc.kyoto-u.ac.jp/services/comp/pdf/file_loss_insident_20211228.pdf
バックアップスクリプトには、find コマンドにより 10 日以上古いログファイルを削除する処
理が含まれています。スクリプトの機能改善と合わせて、find コマンドの削除処理に渡す変数名
を視認性・可読性を高めるため変更いたしましたが、この修正したスクリプトのリリース手順に
考慮不足がありました。
bash は、シェルスクリプトの実行中に適時シェルスクリプトを読み込みます。この挙動によ
る副作用を認識できておらず、実行中のスクリプトが存在している状態でスクリプトの上書きに
よりリリースしてしまったことで、途中から修正したシェルスクリプトの再読み込みが発生し、
結果的に未定義の変数を含む find コマンドが実行されてしまいました。この結果、本来のログ
ディレクトリに保存されたファイルの削除をする処理ではなく、/LARGE0 のファイルを削除し
てしまいました。
（※たぶん変数が空になってしまったので、実質的にrm -rf /が走った）
>>60
絶賛稼動中にやったんか
>>60
いかにも書きそうなスクリプトなんだよな
怖いわぁ
>>60
この説明が本当なら、別のHDD用意すれば今すぐにでもバックアップ再開出来るだろうに
>>60
つまり、どういうこと？
>>333
修正前のスクリプトが稼働中だったのに、そのスクリプトを修正してしまった。
bash の場合、スクリプトを実行する際はファイルを全部メモリに
読み込んでから実行するのではなく、処理が終わるごとに１行ずつファイルから読み込む。
そのため、変更前のスクリプト実行中だったのに途中から変更後のスクリプトに置き換わってしまい、
想定外の動作（ファイル削除）となってしまった
スパコンで消えて困るファイルなんて実行中の計算関係のファイルくらいでしょ
77寺って凄い量消えたね
>>92
まあシミュレーションで吐き出したデータだから
またバッチを走らせれば取り戻せるよ
時間はロスってしまうが、本人は寝て待てばいいだけ
普通はテープでも保管してるから無問題
新人の頃の俺、相対パスで書かれた削除バッチを見て、怖くて絶対パスに書き換えたことあったな
削除ってこえーよな、やった方もやられた方も気の毒だ
削除はこういうの怖いからDBのレコードすら論理削除でお伺いしてしまうわ
スクリプトなりコードなり組み替えてく中で、カレントディレクトリの位置を変えちゃった状態で相対的にファイル消したりしちゃったのかな？
可哀想
> 過去のバックアップログファイルを削除する処理が,/LARGE0 ディレクトリ配下のファイル群を削除してしまう処理として誤動作
で、ﾛｸﾞﾃﾞｨﾚｸﾄﾘでなく
間違ってﾎﾝﾓﾝのﾃﾞｰﾀが入ってるﾃﾞｨﾚｸﾄﾘ消したわけか
あるある
なんか消そうとしてたら
管理者権限で入ってることすら気づかずに
rm -rf /LARGE0
みたいなｺﾏﾝﾄﾞを寝ぼけてたら打ちそうになるしな
>>169
寝ぼけてるときは結構ヤバい
昔ファイル名変更しようとおもって、「リ」ネー「ム」とつぶやきながら rm を実行したからなw
動作中のスクリプトがある中でその構成ファイルを上書いちゃって起こった事故だとすると、そのスクリプトは最初から実行した際にはきちんと動くものなんだよな。
だとすると、
>ファイル削除期間:2021年12月14日 17時32分 ～ 2021年12月16日 12時43分
その動作中のスクリプトは 2日弱動き続けてたってことか。
find するのにこんだけかかる程の大量のファイルがあったのかバックアップの過程で /LARGE0 のファイルのコピーが発生して時間食ってたのか分からんが、
とにかくファイルはいっぱいありそうだな。
8TBのHDD10個とかたいした量じゃないな
>>208
80TＢのを1個で済ませるってやり方もあるけど
クラッシュすると全部逝ってしまうって問題あるから
わざと小分けするってのをやる場合もあるよ
900ギガくらいデータ入ってたHDDのパーティションがふっとんでtestdisk使ってなんとか復旧したな
古いパーティションの残骸が複数あって余分に時間がかかってしまった
それやった月は例年より2割くらい余分に電気代かかった
