6年間営業を続けてきた JournalSpace というブログサービスのデータが、元従業員によって消されたらしい。データ復旧専門の会社に依頼したところ、ハードウェア的な問題はなく、ディスクイメージも復元できたが、データがセクタ単位で上書きされていたとのこと。サービスを続けられなくなった同社は、JournalSpace のソースコードをオープンソースにし、ドメインも売りに出すことを検討している。



<blockquote>

Tuesday:



Journalspace is no more.



DriveSavers called today to inform me that the data was unrecoverable.

(snip)

There was no hardware failure. Both drives are operating fine; DriveSavers had no problem in making images of the drives. The data was simply gone. Overwritten.

The data server had only one purpose: maintaining the journalspace database. There were no other web sites or processes running on the server, and it would be impossible for a software bug in journalspace to overwrite the drives, sector by sector.

(snip)

So, after nearly six years, journalspace is no more.



http://journalspace.com/世界はこうして終わる/爆発ではなく卑怯者によって.html



火曜日：



Journalspace はもう無い。



今日、DriveSavers（データ復旧専門の会社）が電話をかけてきた。データは復旧不可能だと。

(略)

ハードウェアトラブルではなかった。ドライブは2つとも正常だった。DriveSavers はドライブのイメージを取りだすことに成功したけれども、データは無かった。上書きされていた。



データサーバには、journalspace のデータベースしか置いていない。他のウェブサイトを置いたり、プロセスを走らせたりはしていない。それに journalspace のソフトウェアのバグだとしても、ドライブをセクタ単位で上書きするようなことはできない。

(略)

そう、6年近く営業してきた journalspace は、もう無い。

</blockquote>

<p>現時点で示されているデータ復旧方法は、Google のキャッシュから取り出すことのみ。データの復旧には、web archive も役に立つのではないか。ただし、全てのデータが残っているわけではない。以前、知人に数年前のブログの復旧を依頼されたときに web archive から取り出したのだが、一部しか残っていなかった。一番いいところが取りだせなかったようで、残念。</p>

<blockquote><p>It was the guy handling the IT (and, yes, the same guy who I caught stealing from the company, and who did a slash-and-burn on some servers on his way out) who made the choice to rely on RAID as the only backup mechanism for the SQL server. He had set up automated backups for the HTTP server which contains the PHP code, but, inscrutibly, had no backup system in place for the SQL data. The ironic thing here is that one of his hobbies was telling everybody how smart he was.</p>

<p>This doesn’t excuse what happened, though: I should have taken a better look at what he’d left behind, and fixed all of the things that needed fixing.</p>

<p>彼がITの担当者だったんだけど（そう、会社から盗みをやらかして私が捕まえて、辞めるときに何台かのサーバを壊していった奴だ）、その彼こそがデータベースサーバはRAIDを使うからバックアップはしないと決めた人だった。ウェブサーバのPHPコードは自動バックアップを取っているのに、データベースでやってないというのは不可解なんだけども。いかに自分が優秀かと皆に言うのが彼の口癖だったというのは、皮肉だね。</p>

<p>起きたことへの弁解にはならないけど、彼がやらかしたことを把握して、対処しておくべきだった。</p>

http://journalspace.com/blog/

</blockquote>

<p>自分も、最近はホスティングサービスやクラウドと呼ばれるところにデータを置いて安心している。仕事用、プライベート用も含めて、ローカルのPCのバックアップは、もう数年間も取っていない。メールは GMail、ブログは Blogger、写真は Picasa、ウェブのホスティングは Google Sites と GoDaddy と Amazon。どれも信頼できる業界のリーダー的企業だ。Google は3箇所以上にバックアップを持っているなどと聞くと、自分でデータ消失への予防をするよりも、よほど堅実であるように思える。それでも、100% の絶対はない。</p>

<p>できるだけ自前でもたずにクラウドで生きたいので、クラウドのデータを別のクラウドにバックアップしようかな。Google や GoDaddy は S3 にバックアップするとして、S3 がメインストレージになっているデータはどこに置こうか。</p>

<p>しかし、ユーザのデータを預かっている企業が、ユーザデータのバックアップを取っていないというのは恐ろしい。私が以前運用していたサービスでは、安価なディスクを使う代わりに、MySQL のマスタとスレーブの組み合わせで、ほぼリアルタイムなバックアップを行い、操作ミスなどに備えて、一日一回のスナップショットのバックアップを、マスタとスレーブそれぞれで取っていた。データの復元テストも兼ねてバックアップから取得したデータで分析などをしていたため、万が一のときも絶望的な状況にはならないはず。万が一は起きなかったけれども。RAID だけなんて、心臓に悪い。</p>

<p>これでしばらくは、データバックアップをビジネスにする人たちのセールストークが増えることだろう。GMail などのデータを、S3 などのクラウドに自動バックアップするツールやサービス、誰かが作ってくれないかな。GMail Backup を GMail 以外のサービスにも広げて、クラウドに保存するようにしたやつ。ID やパスワードを渡さなければならないから、自分でできる技術者はツールの方を好みそう。一般ユーザはサービスの方がありがたい。</p>

<iframe src="http://rcm-jp.amazon.co.jp/e/cm?t=x03c-22&o=9&p=8&l=as1&asins=4774134325&md=1X69VDGQCMF7Z30FM082&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=FFFFFF&bg1=FFFFFF&f=ifr&npa=1" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe> <h4>参考</h4><ul><li>TechCrunch - JournalSpace Drama: All Data Lost Without Backup, Company Deadpooled</li>
<li>TechCrunch - JournalSpaceの悲劇：バックアップ取らずに全データ喪失、倒産</li>
</ul>