アプリで作成
2021年12月29日

京大のスパコンのデータが約77TB消失してしまったらしい。約28TBは復元不能。日本HPの報告書には『弊社100%の責任』『補償はご意向に沿うようにする』と絶望しかない文章が並んでる…。

あばばば
469
ポテイト @potato9841

日本HPが京大のスパコンのデータを約77TB消失してしまったらしい。そのうち約28TBは復元不能…。 お知らせ内にある日本HPから出された報告書には『弊社100%の責任』『補償はご意向に沿うようにする』と絶望しかない文章が並んでる…。 iimc.kyoto-u.ac.jp/ja/whatsnew/in… pic.twitter.com/7NFA4iAj2G

2021-12-29 01:28:01
拡大
拡大

感想

〽︎いお / Io @121Tkn

いいねできない案件 年の瀬にこんなことが… twitter.com/potato9841/sta…

2021-12-29 10:31:18
もち @MochiPro

一度でいいから言ってみたい日本語 弊社100%の責任 twitter.com/potato9841/sta…

2021-12-29 10:32:32
DAISUKE 卍 リベンジャーズ @daisuke_gtb

読めば読むほど身がつまされる思い・・・。原理は大変よくわかるがシェルが実行中に下位のファイルを上書きするってまぁ・・・迂闊だったとしか言えないよね。 と、ELBの設定不備で均等に負荷分散されなくて年末繁忙期のお客さんサービスを危うく止めそうになったのでTOP監視しながら思いました。 twitter.com/potato9841/sta…

2021-12-29 10:30:10
はる💉💉 @I_HaL

データ移動用のHDDに残してたりしないのだろうか。 twitter.com/potato9841/sta…

2021-12-29 10:29:33
マスターケイオス @tescargot

う、うわぁ… これはヤバい… 消失してしまったデータ量もヤバいけど、要因がストレージのバックアッププログラムというのもヤバい。 まさか、客先リリース前のテストをやらなかったって事はないだろうし、こんなのどないせいちゅうねん… twitter.com/potato9841/sta…

2021-12-29 10:29:21
ひとり🌱💉💉 @Stdal_23

個人や企業のクラウド系も含めて、こういう事件これから山のように増えそう。 twitter.com/potato9841/sta…

2021-12-29 10:27:33
宇宙猫ながよ🧼 @Nagayo0318

約77TB分のスパコンデータ(約28TB分は復元不能)、もはや金銭に換算できるような代物ではない(金額をつけようと思えばできるけど、ほんまにプライスレス&時間をかけて再入手するしかない)ので、補償はご意向に沿うしかないんだろうな…ぎえええ…… twitter.com/potato9841/sta…

2021-12-29 10:26:43
みり🍚 @milli_nell

こういうのを見ると分散化の重要性を感じますね… twitter.com/potato9841/sta…

2021-12-29 10:25:32
あ〜る菊池誠(反緊縮) @kikumaco

こういうことは起こりうるので、データは極力手許にもバックアップしておくべきなんですが、TB級のデータとなると手許に持ってくるだけでも大変だから難しいね。僕はGBのデータだからまあ大丈夫なんだけど twitter.com/potato9841/sta…

2021-12-29 10:24:55

やっちまった感

在宅弁護士(書斎の王様) @master_of_den

恐ろしいものを見てしまった 大掃除も良し悪しですねぇ・・汗 >不用意なプログラムの修正とその適用手順に問題があったことで,本来は不要になった過去のバックアップログファイルを削除する処理が,/LARGE0 ディレクトリ配下のファイル群を削除してしまう処理として誤動作しました. twitter.com/potato9841/sta…

2021-12-29 10:22:49
井戸蛙 @idokawazu_5

研究者のローカルデータでどれくらいかか個別に復活出来んもんだろうか。 twitter.com/potato9841/sta…

2021-12-29 10:21:48
残りを読む(20)

コメント

EARL @EARL_N 2021年12月29日
会社のダメージはもとより、研究機関への影響を考えると絶対リカバリーできない……
209
富士山麓ωナックル @Mqzer9ltQN2nxiE 2021年12月29日
これで論文の締め切りに間に合わない人とか出るのかな?金額での補償とか無理そう。
74
あっきぃ。@いろいろつぶやくやつ @akkiy_ya 2021年12月29日
研究成果が丸ごと電子の海に消えてる可能性とかあるのが怖い。
166
サツキ@雑多垢 @bbs_teck_shye 2021年12月29日
この後、さらに詳しく“これがない!もう手に入れられない!”と絶望が押し寄せるんだよな…怖くて泣いちゃう。
120
さかきみなと⛅榊鐵工 @syouth 2021年12月29日
約28TBにデータがかぶった研究者は、死にたくなるほどの絶望を味わってると思う……。(´・ω・`)
65
暮れ色みかん @nana339 2021年12月29日
卒論の研究結果が消えてなくなったとか、想像するだけでゾッとする…
74
せみ @junh50503128 2021年12月29日
バックアップがどこにも存在しないという話なの?
0
ABルッツィ @LdSDdA 2021年12月29日
やった側の気持ちになると心臓が痛いがやられた側の気持ちになるとブチギレ案件すぎてもう……
174
まきにょ @makinyopp1 2021年12月29日
計算元データは別に保管してある可能性高いとは思うが…計算し直すだけでどれだけかかるのかってのと、それやるにもこの先の本来の運用スケジュールが全部埋まってるだろうからどうすんのと
45
ぽんぽん @apocalypse1706 2021年12月29日
でもこのくらいの容量なら普通に全容量バックアップしててもおかしくない気はするんだよね。そのバックアップがない、ってのはHP側の不手際かもしれないな。
6
JellyKuratin😈 @warknkr 2021年12月29日
データが消失してしまった方達はいくら泣こうが怒鳴ろうがデータがもう二度と戻らない事実だけある事がほんと辛い…
79
白石玄人 @ShiraishiGento 2021年12月29日
>『弊社100%の責任』『補償はご意向に沿うようにする』  武士の時代だったら一族郎党腹切って詫びるレベルのやつだ…。
160
nekosencho @Neko_Sencho 2021年12月29日
とはいえパソコン用に売ってるHDDで一台14TBとか普通にある時代、バックアップをもう一つ増やしておいてもよかったんじゃないかな感はそれなりにある
23
moxid @moxidoxide 2021年12月29日
実行中のシェルスクリプトを上書きした時の副作用に気づかず、古いログ削除ルーチンに未知の変数ぶっこまれてミラーリングの片側モロっと削除とか心臓が痛い
13
白石玄人 @ShiraishiGento 2021年12月29日
重責で済ますにも重すぎるこの文書を自分が書かなければならないと考えたら、飯が喉を通らないどころか口からも尿からも血が出そう…。
127
nekosencho @Neko_Sencho 2021年12月29日
もちろん、「元データは膨大にある中で、たまたまそこだけ欠けた」のだろうけど、その膨大なデータをもう一つバックアップできなかったものかね、と。
1
結城真@社内秘 @shinokiwa 2021年12月29日
バックアップ処理の誤動作ってことは、最新のバックアップは取れなかったということだから、それが復元不能だった分ということなのかな? いずれにせよIT屋には年の瀬に見たくないニュース…。
52
tobo1103 @tobo1103 2021年12月29日
nana339 タイミング的に、卒論修論博論に影響があったら…。その場合、春の学会シーズンも影響出そう。
41
クロックル @clock10_10 2021年12月29日
金で解決ってレベルじゃないな。年末に嫌なものを見てしまった…
11
たけし🐕 @takeshi17922255 2021年12月29日
日本ヒューレット・パッカードは今は日本HP(PCやらプリンタやらで有名な)とは別法人なので混同しないよう注意
110
@azumix2015 2021年12月29日
そんなこともあろうかと…誰かの手元にバックアップがあったり…しないんだろうな…
6
mikunitmr @mikunitmr 2021年12月29日
1週間分くらいテープでバックアプってしてなかったんかね。自社ではテープ何巻も並べてた記憶。
1
うつお @U_2O 2021年12月29日
azumix2015 ちうごくが持ってるかもしれない(ブラックジョーク)
51
うにうにぃ @unie_uniee 2021年12月29日
takeshi17922255 あー、分社化したんでしたっけ?
4
陽樹@陽輝 @scope_scoop 2021年12月29日
最新のバックアップとろうとしたら間違って消してしまったというワケじゃないんか。バックアップがないってことはそういうことかと思ってた。最新から過去とっておいた差分が28TBあるのかと
1
🤖 @zinseitanoshiin 2021年12月29日
機械強くないので一体どれぐらいの規模のデータなのか分からないけど、みんなの反応からするに100人程度の連絡先(自分の職場ぐらい)とかじゃないみたいでビビる…
4
たけし🐕 @takeshi17922255 2021年12月29日
unie_uniee 米の本家がエンタープライズ向けのHPEと個人向けのHP incに分かれて、日本法人もそれぞれ別個に持ってる状態ですね(前者が日本ヒ、後者が日本HP)。分野がほとんど重ならないんで普段は問題ないけど、こういう時はHPのほうに風評被害がw
30
白石玄人 @ShiraishiGento 2021年12月29日
これはただデータが消えただけじゃなくて、研究の断絶、ひいては発展するべきだった技術の喪失だもんな…。
84
くまラブ @yuki_korotyan 2021年12月29日
ランサムに感染したPCによってグループ全体のPCに影響が出たことあったけど、本当に復旧大変だった… システム開発用のテストデータとか量が多すぎてローカルのHDDに置いてたし。
4
いぬだわん @InuWang 2021年12月29日
起動中の確認しないか自動起動を止めずにシェルの入れ替えしたら、シェルの実行途中にソースが変わっちゃった 新旧ソースで変数名が異なるからその差で変数が空の状態でfindが動いて固定文字列部分だけ有効になり大量のファイル/ディレクトリを削除しちゃった 起動中の確認とかいつもやってるとは言え再度気をつけよう
15
名前はまだない @774rider 2021年12月29日
Neko_Sencho 多分予算がないよ。本来なら学部ごととかでバックアップサーバを持つべきなんでしょうけど。
53
RAIYA@提督 @RAIYASB 2021年12月29日
救出可能なデータはバックアップ側から戻せそうって事かな 不可のやつは今回アップデートがあったやつか、前回バックアップから事故までの間のデータなのかねぇ
4
くまラブ @yuki_korotyan 2021年12月29日
yuki_korotyan たまたま1か月前に異動していった人が、前任の担当者&開発データ入りPCをそのまま残す&そのPCは電源オフでネット切断してたから2日で開発自体には戻れた。それでも一年分のテストデータ飛んでるから今もデータ足りないってのがたまに起きる。
6
ぽんぽん @apocalypse1706 2021年12月29日
zinseitanoshiin 面白いこと言うなあとは思ったがw、想像しやすいように言い換えると、例えば君のところの会社のデータはもちろん、取引先全部(連絡先じゃなくて、取引先「が」扱っている全データ)のデータが吹っ飛んだみたいな感じ。
45
フ一口 @fu_hitokuchi 2021年12月29日
これを機にバックアップに予算をつけろと脅しをかけないと……でも大学運営は大体研究のことなんてなんとも思ってなくて定時で帰ることしか考えてないからな……
46
はせ @hakase_D 2021年12月29日
計算結果や経過だけではなくて計算材料まで消失したんだろーか
6
Off Black @OffBlack1 2021年12月29日
またIT業界黒歴史の1ページが…。関係者じゃないけど、読んでるだけで心拍数が上がるし、胃が痛い…。
47
天狗っ鼻のような反り返り @z_r2c 2021年12月29日
本番環境でやらかしちゃった人 Advent Calendar へのノミネートされてるかな?
9
創作文芸サークル時の輪@通販受付中 @Kamimura_Maki 2021年12月29日
本当にこの通りだったら胃が痛い。中国かどっかのエージェントの仕業でした、の方がマシなやつ。ただ中国はこの手のデータは「盗む」だろうけど、単純消去はやらないだろうからなあ・・・。
6
みっどがる @MidgardListener 2021年12月29日
LARGE0ディレクトリがどのように運用されていたのか知りたい 名称からして大容量ストレージなんだろうけど、一時保存用とかならまだ救いはあるはず
5
anko @ankooftheworld 2021年12月29日
新米担当者の迂闊な操作とか、繁忙期ゆえのオペミスとかではなく、実行スクリプトのバグということであれば、お気持ち的な情状酌量の余地もないなあ。
9
カズマサみんC @mskazumin 2021年12月29日
失ったものが何だったか精査してる人の精神が崩壊してしまっても不思議ではないな。関係者各位のメンタルヘルスは十分に。
62
ヌゥスピリット@異常既婚男性 @stillsnash 2021年12月29日
「パラメータ一個でもトチると大口顧客データが全部パッパラパーになるメンテ」の手順書担当になったとき「息を吸って、吐いて、冷静になれたら、ゆっくりと画面の表示を視認せよ」「不安を覚えたら指を止めよう」みたいなメンタル系の文言を赤太文字でデカデカと何回も置いといたら、レビュー担当の上司に「ミスを怖がる性格のお前がここまで書くということは、それだけ危険な作業という事なんだな…ちょっとコレ断れないか営業と顧客に連絡してくるね...」とポツリ。(断れたとは言ってない)
113
lily @katsuasada 2021年12月29日
見ただけで胃がギリギリする。気付いた時の血の気が引く感覚、探してもないことの焦り、上司に報告する時の恐怖、上司同僚にこの年末にリカバリ手伝ってもらう時の申し訳なさ、どう頑張っても復元不能データがあると結論が出た時の絶望、顧客へ連絡する時の悲壮感、全て想像出来るし多分想像の何倍もでかい
112
anko @ankooftheworld 2021年12月29日
業界的にはHPEは安かろう悪かろうなポジションだから、本当に重要なデータを保管するところ(大銀行とか)はもっとちゃんとしてて高価な製品(IBMとか)を使うんだけど、大学や公共はお財布が小さいからHPEばっかりというのも実情としてあって、まあこういうことも起こるよねという気持ちも正直あるわいな。
44
sake @sake_ne_ku 2021年12月29日
一拠点単一システムにデータを保存するのがいかにリスクが大きいかというところだな 77TBとはいえ、単にバックアップするだけなら今時20,30万程度で市販品でも調達可能なわけで、障害対策をした上で自己防衛するに越したことはないな
4
ネワノ @One_of_Engineer 2021年12月29日
nana339 大学として供しているサービスでの広範囲な有害事象由来だから、卒論くらいなら、救済措置があってもおかしくないかと。ただし、「年明けまで救済措置有無が不明」で胃の痛い正月いえるでしょうけど…
36
lily @katsuasada 2021年12月29日
mskazumin 全然この規模じゃないけど、前いた会社で大型連休前に出向で来てた委託業者がデータクラッシュさせて、大型連休中一人で夜通し作業した上で非常階段から飛び降りました。正直上司共々クビは免れないだろうし社内で針の筵だろうけど、メンタルケアや転職支援はしてあげて欲しい
98
🤖 @zinseitanoshiin 2021年12月29日
apocalypse1706 そ、それは全く仕事できないレベル…。エグすぎるて…
8
犬だよ @yaju5123 2021年12月29日
Neko_Sencho 24h365d稼働のサーバーのバックアップやぞ。個人ユースとは金額の桁が違うわい……。
83
とんまのまんと💙💛 @mmantle3 2021年12月29日
これで修論とかぶっ飛んだマスターとかいそうで… 何億円掛かっても仮設のスパコンを提供して並列処理可能にする位しか出来る事が思い付かない(´・ω・`)
8
やし○ @kkr8612 2021年12月29日
関係者全員の寿命一割くらい縮みそう
3
Record.3316 @yamd22163349 2021年12月29日
バックアップが大切なのはわかるが1TBのバックアップだって大変だというのに
22
あびゃあ @wataame_abya 2021年12月29日
zinseitanoshiin iPhoneの容量が64GBだとすると、iPhone16台で1TBになるので77TBだとiPhoneが大体1232台分ですね。連絡先、とかですらなく。システムとかゲームとかその他諸々含めて。
29
よし(海 野) @Yoshinano_SM 2021年12月29日
デジタル化の弱点とはいえこの規模は背筋が凍りますね…
16
あびゃあ @wataame_abya 2021年12月29日
自分で言っといてなんだけどえげつない容量で草も生えない。卒論とかはまあ……個々人のPCやらスマホやらにバックアップとってあるかもしらんが……
23
みずの とんび @lunatic_tonbi 2021年12月29日
データが消失した経緯がまったく分からない
1
だりい @dariidariidarii 2021年12月29日
これさ、損害賠償問題になった時に金額換算でどれくらいの損害が認められるんだろうなあ?最終的に「カネの問題にしちまったほうが楽」だという発想に至って更に泥沼の展開になるような気がするけど。
35
🤖 @zinseitanoshiin 2021年12月29日
wataame_abya 1232人のスマホの全データ紛失レベルか…。自分なら死んでも死にきれん…
4
野良猫さん @as681700 2021年12月29日
何人辞めることになるのだろうか
1
結城真@社内秘 @shinokiwa 2021年12月29日
wataame_abya zinseitanoshiin iPhoneのデータ仕様をしらないのでものすごい雑計算ですが、500万人くらいとお友達になれば1GBくらい埋まると思いますよ。なので64GBなら3億2千万人とかお友達作れば埋まるかもです。 まあ数の上限ありそうな気もしますがw
5
へのん@投信検討中 @dettenten 2021年12月29日
何人のクビが飛ぶんだろうな。いや物理でクビ括るのだけはやめてな。
35
ファング・リウ @FangRyu 2021年12月29日
ただただ恐怖しか出てこないぞこの案件。ノーベル賞ゆかりの研究データとか存在してたら、と思ったらタヒねる(そんな重要すぎるデータは無いと思うけど)。
12
ファング・リウ @FangRyu 2021年12月29日
(トゲッター投稿、タヒの漢字1字が禁止ワードになったようだ。)
6
結城真@社内秘 @shinokiwa 2021年12月29日
77TBという容量が目立っちゃうけど、これ「スパコン使って作るデータ」77TBなので、単純にデータ量だけの問題じゃないから変なテンションになる。
56
鈴木 ゆーむ @yuyumu_ikuzus 2021年12月29日
死人1〜2人くらい出ませんかね、これ
5
Mizuta Fumitaka @Humi_TW 2021年12月29日
日本ヒューレット・パッカード合同会社から提出された報告書の「3 ファイル消失が発生した原因」を読むと、誰でも犯しそうなミスである事が解るから、他人事だけど、まぢで血の気が引いてきて胃が痛くなった。このミスを教訓として再発防止に努める…位しか今は言えないのが厳しいね。
45
Ayuha @aymhtnk 2021年12月29日
shinokiwa 希望的観測を言うなら、(1)スパコンのユーザディレクトリは失敗した時のダンプファイル(たいてい不要)で膨れがち、(2)スパコン利用申請時に「計算終わり次第にローカルにコピー」を口酸っぱく言われるので、習慣にしてる研究者が多い、(3)計算中・計算終了直後のファイルは含まれていないらしい、ので容量から受ける印象よりは多少はマシに......、ならんかな。
48
ばしにぃ @hiro_orso_viola 2021年12月29日
以前クラウドで似たようなことをやらかして存続できずに消えたストレージ会社があったっけ…
18
@mimisomegood 2021年12月29日
何をどうしたってこの手の失敗は絶対無くせないしもう人類全員この世にあるものは全て諸行無常の精神を身につけた方がいいのでは…
2
Tadashi @tadashifx 2021年12月29日
やられたほうが「ふざけんな!」になるのは当然だと思うけど、私としてはやらかした側も心配。当然叱責されるとは思うけどあくまでも業務上の過失と捉えて手順やシステムとしての再発防止策検討のめの聞き取りは行うにしてもあまり強く責任追及はしないで欲しい。やらかした側の自責の念は想像するだけで胃が痛くなる。「いのちだいじに」で周りもフォローしてあげて欲しい。
83
丁 了(3回接種済み) @hinoto_ryo 2021年12月29日
富岳の使用時間を確保したり、富岳と同じ機体を使ったスパコンを調達・設置したりして再計算時間をお金で賄う+サルベージチーム派遣してフィールドワークめいた手法で地道にかき集めて復元を目指す、くらいしか贖いようがないような…。
3
Mizuta Fumitaka @Humi_TW 2021年12月29日
aymhtnk /LARGE0 が何なのかによって状況は大きく変わってくるのでしょうが、利用者がローカルコピーを取っている可能性は大いにありますね。スパコンの運用については門外漢なので実際が分かっておりませんが…
2
tamamizu@お絵描きド素人 @TamamizuTM 2021年12月29日
どうでもいいけど、京大ホムペの文章の句読点が.,で好感持てる
5
551love @551love 2021年12月29日
HP側で保険入ってそうだけど、この文面は保険使えなさそうな気がする。使えるんかな? 自社で全部かぶるんかな、、金銭に見積るだけでも大変そう。
0
ほろ酔い気分 @pokpoku111 2021年12月29日
赤塚不二夫「2度目だからもっと上手に書けたよ」なんてわけには行かないよな・・・
5
Shiro @shiromagenta 2021年12月29日
pokpoku111 退官した人が作ったものとかはどうしようもなく
7
がそ @gaso 2021年12月29日
削除処理+バックアップ処理の動きだと、単に空のデータをバックアップして、気づいたときには空っぽの世代が占めてるってことになるのよね。。
3
さすらい狼 @PzhHugWAatQJqSM 2021年12月29日
でも、28TBって6TBのHDDが約5本分だと考えると、大したことない気がする(白目
0
TKM @TKM42296758 2021年12月29日
hiro_orso_viola ファーストサーバのことなら、クラウド利用料金の返金くらいしかしてない上にクラウド業からはさっさと手を引いてたから、それが理由で潰れたワケじゃないような気も。 HPは何したんだろう・・・
1
ハチミツゥ(「🍯・ω・)「🍯 @86sitor 2021年12月29日
ちゃんと責任を負ってるだけ偉い。事態が事態だから当たり前だけど
4
タバ山 @Irukukwu 2021年12月29日
年明けにDBのメンテしなきゃいけないのにこんなニュース見たくなかったわ・・・
4
Daregada @daichi14657 2021年12月29日
担当者「そうだ これは夢なんだ ぼくは今、夢を見ているんだ 目が覚めたとき、 ぼくはまだ12歳 起きたらラジオ体操に行って、 朝ご飯を食べて、涼しい午前中にスイカを食べながら宿題して、 午後から友達とプールにいっておもいっきり遊ぶんだ・・・」
52
業務用 @gyomu_yo 2021年12月29日
シミュレーションの中間データとかデカくなるけど1ステップ毎にバックアップ取るとか色んな意味であり得ないから、ものによってはもう一年とかはまぁ、仕方ない。
0
フルバ@も~っと!狂犬ちゃん @furubakou1 2021年12月29日
なにも悪いことしてないのに謝りたくなる気分。
11
ひもたろう @himotarou 2021年12月29日
どんな文学作品読むより心が痛むなぁ(´・ω・`)
25
tobo1103 @tobo1103 2021年12月29日
shinokiwa 自分はシミュレーションを仕事にしてた。データ量よりそのデータを得るまでの計算時間を考えると…。 aymhtnk データがでっかいだけで、傷は浅いといいですね。
5
婚活失敗で生涯独身となってしまった男 @failed_konkatsu 2021年12月29日
こういうミスさあ…「もうどうにもならない」を担当だけが理解してる状態から、上司やら顧客やらに復旧策は無いのかとか、何世代前なら戻せるとか無いのかとか、色々尋ねられるのを「どうやってももうどうにもならない」と淡々と相手方が絶望する現状を釈明しないといけない心境を思うと本当にキツいよな
98
mlnkanljnm0 @kis_uzu 2021年12月29日
俺もエロ画像と薄い本のスキャンデータバックアップしとこ。
2
Requirer @Requirer8 2021年12月29日
補償が億で済むといいね。
1
らんとん @Ranton555 2021年12月29日
消えたのが不必要なゴミデータだけであって欲しい…
7
婚活失敗で生涯独身となってしまった男 @failed_konkatsu 2021年12月29日
Ranton555 77TB分のゴミデータの保管場所にわざわざお金かけないよ…
11
お猿さん@轟驫麤 @mamachari3_Jpn 2021年12月29日
本宮ひろし「やぶれかぶれ」では本宮が持ち込んだ原稿が編集長じきじきのダメだし&ボツ喰らって目の前でびりっびりに引き裂かれてしまい傷心の本宮がトボトボと編集部をあとにした翌日、まるっきり同じ原稿携えて編集長に突き付けて「昨日のアレ、コピー機で作成したバックアップ画像だったんだぜ(ドヤ顔)(意訳)」な会話をしてて。バックアップの重要性を学んだ14歳でした。
23
むげん @mugen_ju 2021年12月29日
削除処理直前の変数チェックを入れておけば・・・
1
うのはな透🔞 @unohanaT 2021年12月29日
「bashは、シェルスクリプトの実行中に適時シェルスクリプトを読み込みます(略)実行中のスクリプトが存在している状態でスクリプトの上書きによりリリースしてしまった」これは私もうっかりやっちゃいそう……気をつけよう
4
さん @duanty17 2021年12月29日
やってしまった人のPTSDが心配だ。 良心のある人間なら罪悪感のあまり命を断ってもおかしくないレベルの事故。 バッシングなら利用者から嫌というほど浴びるのだから、身内だけでもフォローしてあげてほしい。ずっと心に傷を抱えて生きるのはつらすぎる。 もちろん命の次に大事なデータがとんだ人の絶望も計りかねるけど。
39
june1k @pacifist_june1k 2021年12月29日
Neko_Sencho https://www.iimc.kyoto-u.ac.jp/ja/services/comp/supercomputer/ ストレージ容量は24PB(実効容量18.8PB) 14TBのHDDなら1756台相当だね。 これが簡単にバックアップできるかどうかは知らんけど。
15
Yeme @yer_meme 2021年12月29日
恐ろしい……筆舌に尽くしがたい……
10
Tai @atmsphrca 2021年12月29日
賠償どうするのかな。計算前データがあったら計算資源提供するんだろうか。スケジュール遅延まで考えたら損失が雪だるま式に膨れかねないなあ
0
筋トレナースマン@滅びよ人類 @m2_tanaka 2021年12月29日
今は無くして困るデータなんて亡き愛犬の写真くらいしかないが、これや卒論データを他人の不手際で失ったら1時間殴ったあとに足の指から金ヤスリで存在抹消してやりたくなるかもな。
1
ひよよ @hiyobdsm 2021年12月29日
なんかやらかした人(エンジニア)への同情が集まってるけど、直接顧客に頭を下げ説明をする担当の人の心労も相当なもんだぞ。
75
名無詩 @Ricoh774 2021年12月29日
復元不可能なのが全てではなくて28TB分だけで済んだ。それだけでも幸運…… そうと思わなければやってられんよ……
29
はいん・まいやー @reisacker 2021年12月29日
うっわぁ…… 声もでねぇよ。
2
MSどす☁TL48 @msdos148 2021年12月29日
HP側も京大側も、バックアップはどうなってるんだろう。ハードウェアを二重化しても、こういう消失には対応できないから、簡単に安心していてはダメ。まだHPは責任取る意向みたいだけれど、流行のクラウドになると万一の場合は責任取らない契約になってるはず。
7
kartis56 @kartis56 2021年12月29日
プログラムやソースコードはバックアップしてるだろうけど、それが読み書きするデータはなぁ…
1
むぎちゃ @mugicha_gbf 2021年12月29日
スパコンだから研究データとかなのかな?金でどうにかなるもんでもねぇな…。
1
_ @wholescape 2021年12月29日
スーパーコンピュータに接続されたファイルサーバの /LARGE0 だから、大規模計算結果の書き出し先であって、「ファイルサーバ」といわれて一般に想像するような雑多なデータの置き場所や日々蓄積されたデータベースの置かれている場所ではないはずです。
32
yuki🌾㊗️7さい🎉⚔ @yuki_obana 2021年12月29日
そういえばなんかのプロジェクトで計算機丸投げで走らせるときって失敗した場合の下流プロジェクトとのバッファとか失敗時の対応ってみんなどうしてるんだろうね(´・ω・`)パラレルに3箇所に投げる予算はないだろうし工期バッファも取りすぎるほどはできないだろうし…製薬会社の治験がずれ込むのは問題が深刻になるかもなあたりはきちんと並走させてるだろうけど…
0
ばしにぃ @hiro_orso_viola 2021年12月29日
これ直接の原因はrmコマンドの使い方じゃなくて、その前のfindコマンドのオプションにシェル変数使っててそれが未定義状態で実行されたって事かね。 だとしたらシェル変数の初期化(定義漏れ回避)やfindコマンドの使い方の未熟さも要因ではあるが、これ半分はシステム運用の問題でしょう。 動いてる可能性があるリソースをリリースして上書きするなんてシステム更改手順の不備としか思えませんよ。
3
_ @wholescape 2021年12月29日
いま Cray は HPE の子会社になっているから、HPE が社有でもっている(であろう) XC40 を突貫工事で SINET に繋いで計算資源を提供して再計算を間に合わせる…とかになるのかしら…
1
Cook⚡低浮上だけど元気です。 @CookDrake 2021年12月29日
FangRyu 実験してみたけど、「死+ね」だけだったよ。
8
丁 了(3回接種済み) @hinoto_ryo 2021年12月29日
pacifist_june1k バックアップ=コンテナいっぱいのHDDをトレーラーで運び込んで交換、とかそういう規模ですね…。
3
田中一郎 @eggmanpat 2021年12月29日
京大の研究者って、自分が関与したデータ(元データ)は自分のPCに保存しておかないのかな?
1
ovandeyas @ovandeyas 2021年12月29日
年末の仕事終えて帰ってきたらなんでこんな恐ろしいにもほどがある怪談がががががが
9
おねむ @onemu1846 2021年12月29日
心臓がキュッってなった
1
金目の煮付 @kinmenitsuke 2021年12月29日
京大のスパコンのデータが飛んだと聞いて「卒論が」と想像するの、ちょっとかわいい。
20
大枝瑛一@布団帝國幕張領事館💉💉💉 @Hideaki_HuangOE 2021年12月29日
それはともかくとしてhpの全面降伏だそうなので玉音放送のモノマネしますね。 「……只今より重大なる通知があります。全学及び学外のユーザーの皆様、ご起立願います。スーパーコンピューター陛下におかせられましては、全ユーザーに対し、畏くも御自ら大詔を宣らせ給うことになりました。これより謹みて玉音をお送り申します……」
0
大枝瑛一@布団帝國幕張領事館💉💉💉 @Hideaki_HuangOE 2021年12月29日
『朕深ク 技術的限界ノ大勢ト 本學ノ現狀トニ鑑ミ 非常ノ措置ヲ以テ時局ヲ收拾セムト欲シ 茲ニ忠良ナル 爾 全利用者ニ 告グ 朕ハ 日本ヒウレット・パツカアド・リミテツド・ライアビリテイ會社ニ對シ 其ノ共同宣言ヲ受諾スル旨 通告セシメタリ……』
1
とんまのまんと💙💛 @mmantle3 2021年12月29日
wholescape それが一番現実的な対応策なのかも。 とりあえず処理単位を増やして並列処理か? ただ接続回線の事を考えると年明けまでずれ込みだろうか。
0
あらⓅ★ @arapix 2021年12月29日
ドラクエより古より口伝された箴言「だからさァセーブしろって言ったじゃん」を思い出す。バックアップやミラーは無いのか。
0
あらⓅ★ @arapix 2021年12月29日
富士通は優勝旗を無くすがHPは顧客データを無くす、と。
16
K3@FGO残5 @K3flick 2021年12月29日
スパコンデータということは、シミュレーションデータとか蓄積系が主かなあ… コアな研究データとかは入ってないと思うけど
0
大学生になったロウニンスレイヤー @miyoguy344 2021年12月29日
もう一個バックアップ取っとけば、と簡単に言えるが24PBだからなあ。外付けHDD一個買ってくればいいってもんじゃないからなあ
5
クリスセドン @sedooooooon 2021年12月29日
怖い 今仕事のデータはクラウドに全部保存してるけど消えない保証はないもんなぁ
0
Mr. SODATE @HeppokoEther 2021年12月29日
♪データ消して めそめそして どうしたんだい 『弊社100%』
4
navyfox @navyfox 2021年12月29日
28TBという数値が一人歩きしてるけど利用者一人頭だといくらぐらいになってるんでしょうね…。人為的なやらかしにしても外部要因とあってはコントロールは不能ですから、できるもんなら手元にコピーを保持しておくべきだなと思ったなど。
0
クロ。 @AlRescha4251 2021年12月29日
ankooftheworld 上でも出てるけど起動中のシェルがいるところで読み込むファイル差し替えちゃったから半端に動いた結果なのでどっちかと言えばバグじゃなくてヒューマンエラーではないかな だからこそhp側も弊社100%の責って言い切るわけで
8
まきにょ @makinyopp1 2021年12月29日
24PBの中の28TBと聞くと大したことないような気がしてくるw ストレージに組み込まれてる高速バッファが250TBあるそうだ…スパコンの計算結果としてはわりとすぐ埋まる量だったりするのか?
5
大学生になったロウニンスレイヤー @miyoguy344 2021年12月29日
あとHPEは安かろうなのかも知れないが(実情は知らんが)、京大が入れたときはまだCRAYだったはずなので…(というかIBMはintelプロセッサーのスパコン作ってないのでは…)
0
塩川騎士 @shiokawa_knight 2021年12月29日
数十年かけて経過を記録したデータとかあったら……。
0
alan smithee @alansmithy2010 2021年12月29日
原因はこっちが詳しい(検証してみた人もいる) 【エンジニアの悪夢】日本HPE、京大スパコンのデータ77TBをLOST、全面謝罪▶理由を読んだ皆さん「インタプリタ怖い」「胃が痛くなる」 https://togetter.com/li/1822762
8
ポン助 @k_maimai 2021年12月29日
納入側が全面謝罪ってまぁレアよね。しかも間に入ってるインテグレータもいなくてHPEが直で全部対応してたってこと?自分たちの知らん世界もあるんだなぁ。
0
蒼橘慎悟 Powered By BIONTECHx3 @cingoP 2021年12月29日
yuyumu_ikuzus 両手で済めばもうけもんじゃない?ってぐらい出そう。死人同然にメンタル病む人はカウントされないかも知れんが…
1
やまべりく @yamaberiku 2021年12月29日
うわあ・・・ 生きた心地しない
1
hizen31415 @hizen31415 2021年12月29日
One_of_Engineer そもそも自分のデータが消えたかどうかすら、正月明けまで確かめられない人が多そう。
11
VitzRsTurbo @VitzRsTurbo 2021年12月29日
スクリプトのチョンボかあ。テストで見つからなかったのかな?それともやってない?そこが気になる。
0
鳥皮ポン酢 @ai_raw01 2021年12月29日
怒られるけど謝ったら復元がまだすぐできるデータを誤って消しかけただけでも一気に顔の血の気が引いて心臓の鼓動が速くなったのに、これやらかした人のメンタルが心配になる。
1
らくしぃ @x891rksy 2021年12月29日
ヒューマンエラーだと胃が痛くなるから 「敵対国からのハニー・トラップを受けた作業員による過失を装った故意」ってことにしない?
1
結城真@社内秘 @shinokiwa 2021年12月29日
ちなみにシェルスクリプトだけじゃなくPerlやPHPなんかでも同じ事起こるのでサーバー屋さんは注意するように。 インタプリタ全般かは知らないけど前述2つは起こるの確認済み。
1
貝塚英輔 @598424929632 2021年12月29日
こんなポツダム宣言みたいな報告書なかなか見れん。書いてる最中の担当者の心境を思うと胃が縮む。。
6
結城真@社内秘 @shinokiwa 2021年12月29日
shinokiwa 厳密にはファイル内の行単位では起こらないけど、importやrequireで別ファイル読み込むタイミングと被ると起こる。
0
nekora2520 @nekora2520 2021年12月29日
変更の理由がソースの「視認性・可読性を高める為」というから、故障していないものを修理するリファクタリング信者は気を付けろよ…(シェルだからソースもオブジェクトもないけど…)。
4
結城真@社内秘 @shinokiwa 2021年12月29日
nekora2520 これはリリース手順のミスなので、どういう理由で修正しようと同じ方法でリリースする限り誰かは踏んだ地雷ですよ。
4
nekora2520 @nekora2520 2021年12月29日
実行中に置換など論外として、稼働中のMCなシステムの処理の修正においては、それは本当に必須の修正か?を見極め必要最小限に止める事が重要ですね。
0
さく @sakuro 2021年12月29日
set -ue しておけば… (事後諸葛亮)
0
blossom @blossom53884378 2021年12月29日
arapix 「だってさあ 大丈夫だと 思ったもん」
2
みま🇺🇦 @mimarisu 2021年12月29日
歴史的にいうならアレクサンドリア図書館がカエサルにより焼失したレベルかと
10
sorakarajyosi @sorakarajyosi 2021年12月29日
どういうシステムなんだろうと「Lustre」でぐぐったら、東京大学情報基盤センターがヒットするんだけど。こっち大丈夫なんやろか。
0
kokomaro @kokomaro11 2021年12月29日
関係者、ひとまずはどうしようもないので正月は休める…のか? 年明けが針の筵の気がするが
0
Off Black @OffBlack1 2021年12月29日
バックアップしとけばうんたらとかいう人いるけど、そもそも77TBなんてバックアップが到底1日じゃ終わんない容量のバックアップ運用がすでに現実的じゃないんだよ・・・ストレージサーバから諸々考えても金がかかり過ぎるし、もとから背水の陣的ですでになんか詰んでる気がする・・・。こんな仕事受けとうない。
2
Naruhito Ootaki @_Nekojarashi_ 2021年12月29日
ここで問題になってるバックアップって対障害のもので、運用上の対策としてのバックアップは利用者個々人がやってるべきものではないか。だから本来なら被害は軽微のはずで、それを見越しての「ご意向に沿うように」じゃないんだろうか。
5
みる @99_mmgt 2021年12月29日
HeppokoEther 太陽みたいに笑う 君はもういない
3
navyfox @navyfox 2021年12月29日
99_mmgt 太陽は神託に飲み込まれてなくなってしまいましたね…
7
くじら @kujira_desu 2021年12月29日
OffBlack1 テープライブラリに複数ドライブ搭載すれば77TBは余裕だと思うよ。スパコンの予算規模なら誤差の範囲内に入りそう。 影響範囲が77TB、うち28TBが復旧不可、ストレージ全体で18.8PBなので、バックアップ取るなら結構な予算が必要なのは間違いないけど。 https://www.iimc.kyoto-u.ac.jp/ja/services/comp/supercomputer/
1
zoh @Neutrino_shower 2021年12月29日
これ、「論文発表が遅れて、他の研究者が先に発表して、結果的にノーベル賞取り損ねた」級の被害が出る可能性もあるよな。
16
ただのいしころ @ishikoro20211 2021年12月30日
テープストレージ使うバックアップじゃなかったのね、HPもその規格を採用してたはずなんだけど、それだったら一回バックアップしたら、メディアを上書きする危険もなかったろうから、上書きとかそういう危険はなかったように思うが。方法はLARGE0とあるからHDDのミラーリングバックアップか、で、今のテープメディアは書き込みスピードはHDDと同様で、グーグルはこのバックアップ方式を使ってて、GMAILでトラブル起きたときの復帰はそれでやったそうだ。
0
ただのいしころ @ishikoro20211 2021年12月30日
https://asahi.5ch.net/test/read.cgi/newsplus/1640722681/  これによると、将来的にはこれまでのミラーリングによるバックアップだけでなく,1世代分の増分バックアップを残す等の機能強化を検討いたします。とあるから、テープ使えよ。と言えると思う。最もその場合、バックアップを取った後、ファイルを削除してしまうと?整合性が取れないが、そこは大した問題ではないと思いますね。
0
刺身定食 @usytata 2021年12月30日
皆と一緒にヒエッ怖いとか書きたいけど、シェルスクリプトは変数が意図せず定義されてない状態でも(デフォルトでは)エラーで止まらずに進んでいってしまうところが怖い言語で、そのために定番防止策(set -u や ${V:?undefined})が昔からあるんだけど使ってないっぽいし、さらにそれでコードレビュー通ってるのが気になる
8
Captain Carlos @Captain_5thWall 2021年12月30日
この年末に吐きそうなインシデント
0
Captain Carlos @Captain_5thWall 2021年12月30日
今雑に計算した所、12万人程度の生涯のアルバムと日記が消えたってとこかしら
0
にゃかがわ @nyakagawa_r 2021年12月30日
不勉強なので何が起きてデータが消えたのかよく分からないんだけど、本来はバックアップの取れたデータを削除するはずが、その途中でバックアッププログラムを更新した結果、プログラムの設定が書き換えられて、まだ削除してはいけないデータまで削除してしまったってことなのかな。
1
令和ライカ @kait8823 2021年12月30日
やはり連想するのはアレキサンドリア大図書館の消失なんだよな。
1
Hussam Kahn @bbyfut 2021年12月30日
データが飛んだせいでできなくなりました! ていう言い訳で救われることになって内心ガッツポーズしてるユーザーとかは京大だといないのかな
1
KABE@けーあべ @abekoved0902 2021年12月30日
「100%うちの責任」とか「賠償はご意向に沿うようにする」とか言っちゃって大丈夫かな…
0
倭翔 @yamato_kakeru_ 2021年12月30日
abekoved0902 自社の責任しかないのでそれしか言い様がない。 ファーストサーバみたいに「自社の責は約款通りに。サーバ利用料のみ返金します」で逃げられるレベルじゃない。
3
倭翔 @yamato_kakeru_ 2021年12月30日
nyakagawa_r プログラムを動作中に書き換えてエラー処理しなかったので、バックアップ元未定義でバックアップできてないのにバックアップ完了と判断してバックアップ元を削除してしまった、ということ 本来は変数チェックしたり動作中の変更はしない(いったん停止してやり直す)とするんだけれど、そのままGo!しちゃった。
5
倭翔 @yamato_kakeru_ 2021年12月30日
なので、だいたいそれで合ってます。
1
倭翔 @yamato_kakeru_ 2021年12月30日
こういう場合の賠償は会社が負って実行した本人には別途懲戒処分するはずだけど、中には全責任を本人に負わせる場合もある(誓約書にあっても違法。別途重過失責任として再計算した場合は司法が有効とすることもある)からなぁ……本人確保しないと危険だよ本当に。
3
ネクロス @necross000 2021年12月30日
hani_dark_law データセンター規模の数値ですもんねぇ···(スパコンはデータセンター規模の話だけど)
1
さどはらめぐる @M__Sadohara 2021年12月30日
データ移設の際のプロセスとか客と打ち合わせしてないの?
0
YF(annex38) @annex_38 2021年12月30日
編集前の素材がハッキングされたAV会社は身代金を払っていないらしい
0
facatacom @ascarnia 2021年12月30日
バックアップは無かったのかと思ったけどバックアッププログラムの不具合か…バックアップ予備をもう1個作っておくしかないだろうな。しかしそうなると経費が。
0
佐渡丸樹 @sademarquis1 2021年12月30日
---俺用タグ【まとめ主が無能】--- 株式会社日本HPに対する熱い風評被害。やらかしたのは日本ヒューレットパッカード合同会社。
1
佐渡丸樹 @sademarquis1 2021年12月30日
yamato_kakeru_ ちょっと違う。「一定期間以前のバックアップログ」を削除対象とするはずが、「削除対象ディレクトリを保存した変数」が旧スクリプトでは未定義だったため、空文字列に展開されて上位ディレクトリ配下(ここでは/LARGE0)すべてに適用されてしまった。
8
倭翔 @yamato_kakeru_ 2021年12月30日
sademarquis1 訂正ありがとうございます。未定義変数の結果対象ディレクトリがHOMEに設定されてしまった、ですね。bash含めたインタプリタ(PerlやPHPなども)これが怖いんですよね……
0
結城真@社内秘 @shinokiwa 2021年12月30日
なんか一部勘違いしてそうな人がいる気がするけど、/LARGE0はディレクトリじゃなくてファイルシステムなので、一般PCで言えば/dev/sda1とか極論/dev/nullとかに相当するものじゃないかな。
4
かつまた📛あいね📛 @kamiomutsu 2021年12月30日
さすがにまとめ主もスルーしてるが、これに「やはり紙最強」みたいなリプしてる人はネタなのか本気なのか分からなくて困る。
1
ありっせ@何か創ろう2022 @XeroAlice 2021年12月30日
何人首が飛んで 何人首を括るんだ…
0
とんまのまんと💙💛 @mmantle3 2021年12月30日
Neutrino_shower これが残ったデータで証明されたりすると、割と真面目にHPE詰むと思う。名誉の喪失ってお金じゃないからな。
4
特急くろしお37号 @kurosio9640 2021年12月30日
とりあえず当事者全員エンコなのかな・・・
0
豆だ @Osakata6u 2021年12月30日
研究データを失うことは人類にとっての損失。金銭に換算はできない。
0
Ad_Meyer@Modernizedx3🇺🇦 @MCEscher68 2021年12月30日
Kamimura_Maki 何が盗まれたか特定されないように、大規模な消去をかけて証拠隠滅する手口は存在するので、今回もその可能性はまだ排除できない段階かと。
0
ほのか🇮🇹 イタリア留学中の翻訳者 🇺🇦 @honoka_547 2021年12月30日
katsuasada 読んでて泣けてきました。メンタル持ちとして他人事じゃないです…お大事に
0
tgttr @tgttr4 2022年1月1日
データ損失もこの労働環境も世界一位だ
0
TANABE Toshiharu @itinoe 2022年1月1日
詰められた側も居て、詰めた側も居ることを考えると二重三重に胃が痛くなる
0
コシミズショウタ @shotanet 2022年1月1日
学ばせてもらった。bash 見直ししよう。
0
C_CLPS @C_CLPS 2022年1月1日
セガなら1人5000円払って終わり
1
ND@痩せろ @Ndebris_deux 2022年1月2日
石板と粘土板にバックアップするしかないんやな……
0
平尾 由矢(パブリックエネミー) @astray000 2022年1月3日
多分、来年あたりのSEやらかし案件研修ビデオに収録されると思うよ。やったね。(違う、そうじゃない
0
❄️だるMA🐎 @daruma_san_dayo 2022年1月3日
めたくそアナログ人間でも「京大」の「スパコン」てだけでよりによってそこ?!感ある
0
順三朗 @junzabroP 2022年1月4日
PCサーバーの視点から見ると、バックアップ対象のストレージのファイルシステムで先にジャーナルを実行してからバックアップを実行すればよかったのでは? 一旦ジャーナルが完成すれば、その状態でファイルデータが固定されるから、実ファイルを上書きしてもジャーナル時点のファイル情報は保持できるわけだし。
0
順三朗 @junzabroP 2022年1月4日
ジャーナルはext4の場合で最大64個、WindowsのNTFSの場合、ストレージの空き領域のある限り作成可能だから、ジャーナルまたはファイル履歴をちゃんと作っていれば、不用意にファイルを削除してしまってもジャーナルから消したファイルを読めるよ。
0
順三朗 @junzabroP 2022年1月4日
ジャーナル+バックアップの運用をしてないならヒューレット・パッカードが手抜き運用していたのでは? と思ってしまう。ストレージが故障したときに対処するのがバックアップ。ファイル単位の破損や削除に対応するのがジャーナル。役割が違うのだから両方実施すればよい。
0
順三朗 @junzabroP 2022年1月4日
ここまで書いておいて思い出したけど、ジャーナルじゃなくてスナップショットでした。ジャーナルファイルシステムのスナップショット作成ですね。
0
fff @ffffdark 2022年1月4日
junzabroP なんか2つの話が混ざってる気がする。まずバックアップ処理のためのスナップショットの目的は、バックアップ内容をバックアップ開始時点のデータで固定すること。バックアップ処理中の別の処理によるデータの変更が中途半端に反映されるのを防ぐ目的。当然だがバックアップ処理中の変更しかスナップショットに記録されないし、今回の事故が起きたバックアップ処理後の後始末は管轄外
0
fff @ffffdark 2022年1月4日
junzabroP 次に常にデータの全変更を記録するタイプのスナップショット(いわゆるボリュームシャドウ)は10日分保存されてたようだ。なので直近10日間に更新があったデータは消失していないと報告書に書かれている。そしてバックアップの完了時に10日以上前のログが消去される。で、このログを消す処理で事故ったのが今回のケース。 つまりスナップショットとバックアップは両方実施されていて、さらに10日分は両方に残るようになっていた
1
順三朗 @junzabroP 2022年1月4日
ffffdark それはおかしい。ボリュームのスナップショット(ボリュームシャドウ)はボリューム中のすべてのファイルが対象となるのでバックアップ処理後にファイルを誤って削除した場合もスナップショット自体を削除するまではスナップショット時点のファイルは取り出し可能なはず。
0
順三朗 @junzabroP 2022年1月4日
https://www.iimc.kyoto-u.ac.jp/ja/whatsnew/information/detail/211228056999.html 元ソースを読むと古くなったバックアップログファイルと間違えて最新(/Larege0)を削除してしまったと書かれてあって、スナップショットが取られているは書いてないよ。ミラーリングとしか書いてない。
0
順三朗 @junzabroP 2022年1月4日
そもそもボリュームのスナップショットが取られているなら実ファイルを削除したとしてもスナップショットから復元できるのだからこんな問題にならないはずだ。
0
順三朗 @junzabroP 2022年1月5日
FreeBSDのzfs snapshotコマンドでスナップショットを取って追試したけどちゃんと削除後のファイルを読めたから問題ないな。
0
fff @ffffdark 2022年1月5日
junzabroP スナップショットには種類があり、バックアップ処理で使用するもの ffffdark とボリュームシャドウ ffffdark は別の処理。どちらの話がしたいのかわからなかった(「2つの話が混ざってる気がする」というのはそういう意味)ので併記したのでボリュームシャドウの話がならこっちffffdarkを参照して欲しいな。参考:https://milestone-of-se.nesuke.com/sv-basic/design4backup/snapshot/
0
fff @ffffdark 2022年1月5日
用語が違うのでわかりにくいが報告書内の「バックアップログファイル」はあなたの言うスナップショットで使う差分ログファイルだよ。詳しい仕組みはこのあたり参照 (https://docs.microsoft.com/ja-jp/sql/relational-databases/databases/revert-a-database-to-a-database-snapshot) リンク先はDBの話なので「トランザクションログ」と呼ばれているが仕組みは全く一緒
1
順三朗 @junzabroP 2022年1月5日
ffffdark あなたがどう言ったところでスナップショットを取れば誤って削除した後からでも削除後のファイルは復旧できることは実測で確かめられた。日本ヒューレット・パッカードがスナップショットすらまともに使いこなせていないのは明らかだ。
0
順三朗 @junzabroP 2022年1月5日
ffffdark それは即座に否定するのは私はサーバー管理の専門家ではないので難しいけど、少なくとも直感には反するといいたい。なぜならばスナップショットで発生するファイルデータの管理方法の変化は「バックアップログファイル」ではないからだ。だってファイルじゃない。ファイルシステムの状態だから。通常、バックアップ処理で「バックアップログファイル」といえば、バックアップしたファイル名、日付、ファイルサイズ、md5sumあたりを1行1ファイルとして記載したテキストファイルを指す。
0
順三朗 @junzabroP 2022年1月5日
ちなみに zfs snapshotでボリューム単位でスナップショットを作成すると、そのボリューム内に .zfs/[スナップショット名]の隠しフォルダ(lsコマンドで見えない)が生成されるけど、これをバックアップログファイルと呼ぶにはこじつけも甚だしい。これはスナップショット内のファイルにアクセスするためのバイパス手段であって実ファイルではないからだ。
0
altaica @altaica4 2022年1月6日
ジャーナルくんの主張通りだとすると「バックアップログファイル」からデータの復旧はできないことになるけど、「バックアップログファイル」が存在する直近10日間のデータは復旧できているという事実はどう考えてるんだろ?どうやって復旧したことになってるの?
2
altaica @altaica4 2022年1月6日
ボリュームシャドウをzipみたいな圧縮データと勘違いしてそう。差分だけ保存する仕組みじゃないと容量がいくらあっても足らんて。SVNやgitもそうだぞ
0
或見 @alimicrow 2022年1月6日
junzabroP Winと用語が違うので分かりづらいですが、10日前までのフルバックアップと毎日の差分(ログ,ジャーナル)があると思えば分かりやすいですよ。ログは揮発メモリ上にしかない場合もあるので、あえて"バックアップログファイル"としたんでしょう。3日以降に更新した分は差分が残っていてフルバックアップに書き戻せるから復元できるが、していないものは3日までロールバックするという話だと思います。
1
或見 @alimicrow 2022年1月6日
毎日の差分と書きましたが実際はトランザクション毎ですね。一応訂正。
1
順三朗 @junzabroP 2022年1月9日
altaica4 ファイルシステムのスナップショット(シャドウコピー)は対象のファイルにフラグまたはナンバリングするだけですよ。例えば初期状態のファイル構成を0にしてスナップショットを取ると状態が1になる。その後、任意のファイルシステム買い替えを行うと対象がいるのナンバーが1になる。この0の状態と1の状態を両方保持するのがスナップショットの機能です。基本的にファイルシステムに空き容量が存在する限りこれは可能。
0
順三朗 @junzabroP 2022年1月9日
alimicrow 日本ヒューレット・パッカードの報告書を読む限りでは12/3以降更新がなかったファイルが消失対象なので、そもそも12/3時点のフルバックアップが取れてなかったことになりますね。逆に言えば12/3-12/16までに更新があったファイルは復旧できているので差分・増分バックアップは生きていることになる。そしてその差分はいわゆるファイル差分ではなく、更新対象のファイル全体をバックアップしていたと。
0
順三朗 @junzabroP 2022年1月9日
junzabroP 補足すると、ファイルシステムのスナップショット自体は一瞬で完了する。なぜならファイル自体は何も触らず、ファイルシステムのスナップショット番号が1増えるだけだから。例えば初期状態を0とするなら1に変わるだけ。そしてファイルシステムの全ファイルはもともとスナップショット番号0で管理されている。そしてスナップショット後はスナップショット0のファイル状態を保持したままスナップショット1のファイルが作られていく。こんな事ができるのはジャーナルファイルシステムだから。
0