77TBのファイル

京都大学学術情報メディアセンターのスーパーコンピューターに保存していた約77TB分が消失した事件。バックアッププログラムの不具合という事で、開発元のHPが「100%弊社の責」として謝罪して居るわけですが、その原因というか理由がよく分からない。 

記事にも書かれているけれど、

ストレージのバックアップ処理実行中にバックアッププログラムの更新作業をしたことで、

これって、「車のタイヤ交換を走りながらやりました」と言っているように聞こえるんですが。一寸前のOSやアプリだと、使用中のファイルはロックされてバックアップも出来ない場合が多くて、その為データバックアップはそのマシンをオフラインにして実行したり、夜間にやったりという事が「普通」でした。最近はオンライン中でもバックアップ出来るようになり、それは便利かもしれない。作業者の負担も軽減できますしね。それでも、バックアップ作成時には競合が発生したりデッドロックしないように、その領域へのアクセスを停止したりするのが、管理者としては望みたいところ。

それなのに今回の場合は、そのバックアッププログラムの更新をバックアップ中にして居たという、正直どう言う理由というか根拠からそんなことをやったのか分からないのだけれど、正直理解不能。最初に「車のタイヤ交換を走りながらやりました」と書いたけれど、「車のエンジン交換を走りながらやりました」と言った方が正しいかもしれない。一般的な場合でも、バックアッププログラムはの互換性維持のためにも、まずは今のバージョンで一度バックアップして、その後プログラムを更新して、新しいバージョンでもう一度バックアップを作成しておくのが普通なのでは。勿論、そのプログラムの改変度合いにもよるけれど、確実にバックアップデータの互換性が担保出来るならまだしも、そうで無ければ前後で二回バックアップするのが普通だと思う。それなのに、バックアップ中にブログラムを更新するなんて理解出来ない行動だなぁ。

実際HPのレポートにも書かれていますが、バックアップ作業中に実行プログラムが新しい物に変わり、その為にパラメーター指定に不具合が発生して結果的にバックアップに失敗したと説明されています。いゃ、そんなん常識でしょうが、と小一時間。担当者は、一度プログラムが実行されたらそのファイルは使われなくて差し替えても問題無いと思っているのだろうか。いゃ、そう言うデザインなら問題ないけれど、普通はやらないよね。実行したなら、その実行が完了してから更新するだろうし、場合によっては実行時に起動したランタイムとかはまだ残っている可能性もあるから、私なら少なくとも一度再起動してから更新するか、少なくともタスクマネージャーから関連するタスクを終了してから実行するなぁ。まぁ、他社さんの話なのでとやかく言う筋合いは無いけれど、でも原因はほぼ100%ヒューマンエラーな気がする。