カレンダー

2020/06
 
    
       

広告

Twitter

記事検索

ランダムボタン

まるで魔法のように

by 唐草 [2020/06/04]



 「間違ってデータを消してしまったんですけど、元に戻す方法ありませんか?」というおめでたい問い合わせが来た。当然のことながら消す前には警告が出る。強い言葉が並ぶ警告を目にすると消そうと思っていた気持ちまでくじかれそうになる。システム的なガードと心理的なガードを組み合わせているので、ちょっとやそっとのミスでは消せないようになっている。
 そんな状況を掻い潜って消去を選択してしまったのなら、それはユーザのミスとは言えないだろう。明確な意図を持って自発的に削除したとしか思えない。
 しかし、利用者というのは常に身勝手で己の否を認めないものである。普通に使っていたら煙のように消えたと自己弁護を重ねる。そして、消え去ったものを魔法のように蘇らせる方法が存在していて、魔法が使えない管理側は無能だと思っているようだ。
 「都合のいい魔法を使えるならデータを復旧させる前にお前を消してやる」これが偽らざるぼくの本音である。
 ただ、世の中に便利な魔法があると錯覚してしまうのには理由があるのだろう。ぼくは魔法は使えないが、ぼくの複雑な操作は何も知らない人には魔法のように見えても不思議無いからだ。
 ぼくは利用者のことをバカで愚かだと見下している。何も期待をしていないからこそ、彼らがピンチになったときに自分に火の粉が飛んでこないように入念な準備をしている。その1つが多重化されたバックアップである。
 消えたデータは元には戻せないが、消える前のデータはいくつか残してある。
 データが残っていた日のバックアップを確認する。データベースの中身は圧縮して1.2GB。ファイルは合計で2TBぐらいあった。この中から1本の針を見つけ出せれば、消えたデータが復旧したように見えることだろう。復旧環境で圧縮ファイルからデータベースの復元を開始した。
 1.2GBの圧縮ファイルは展開すると10GBぐらいまで膨れ上がった。それをデータベースに戻すのに4時間もかかってしまった。ハッシュ値ばかりでバイナリにしか見えない可読性の低いデータを紐解いていって、2TBのデータのどこに目的のファイル群があるかを見つけていった。
 足掛け5時間。どうにかバイナリの塊を発掘した。
 さて、本番環境に戻すか。そう思って作業を進めたのだが、同じデータが既にあった。
 データは始めから消えてなどいなかったのだ。利用者が消したと思いこんでひとり騒いでいたのだ。この5時間の努力は何だったのだろう?