JournalSpace - 元従業員にデータを消されて営業終了したブログサービス

Jan 4, 2009

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>

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

<blockquote>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.

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.

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

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

http://journalspace.com/blog/

</blockquote>

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

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

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

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

<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>

Android Dev Phone 1 をソフトバンクで使った場合のパケット料金 2

Dec 28, 2008

Dev Phone 1 をソフトバンクで使う場合、選択した APN によりパケット定額フルに含まれるか、含まれないかが変わる。初めに APN として vodafone を使ったのだが、これはマズかった。ソフトバンクから見ると、PC に携帯を接続してモデムとして利用した場合のパケットとしてカウントされているようで、パケット定額フルが適用されなかった。

では、iPhone 3G用の APN (smile.world) ならどうだろう、ということで試したところ、見事、パケット定額フルの分としてカウントされていた。簡単な用件でも、電話すると10～20分もかかってしまうソフトバンクのカスタマーサポートに、2回も電話をして実績値を確認したので間違いない。

ただ、ネットワークに余裕がないといわれるソフトバンクにSIMロックフリーの携帯をつないで定額のパケット通信をじゃんじゃん使われると、ソフトバンクも困るだろう。想定外のトラフィックが増えたら、何らかの規制をされそうだ。その規制がいつ始まるのかは、ユーザーには読めない。キャリアが困れば、それはユーザーに跳ね返ってくる。Dev Phone 1 での 3G は、最小限にした方が、お互いに幸せであるように思う。

ソフトバンクとしては、総務省の先導で2010年に実現するかもしれないSIMロックの解禁と、2009年に日本でも正式に発売されるであろうAndroid携帯と、自社の3Gネットワークのトラフィックを睨みながら、舵取りをしなければならない。ソフトバンクモバイル自身も、2008/12/09 に、Android を推進する Open Handset Alliance (OHA) に参加したことが正式発表された。

なお、電波法的な観点から、Android Dev Phone 1 の日本での利用に法的な問題があるのか無いのか、というのは難しい問題らしく、調べれば調べるほど、よくわからなくなる。日本Androidの会でも議論されている。これについては、総務省に正式に問い合わせている方がいらっしゃるので、30日以内に総務省の見解が明らかになる。

ここで「使ってはいけません」という趣旨の回答が返ってくると、Dev Phone 1 での 3G、Wi-Fi、Bluetooth を使った開発の情報がアンダーグラウンド的に流通、またはぼかして流通することになるので、開発者としては痛い。

参考

Android Dev Phone 1 の日本での利用（日本Androidの会）

dev Phone 1を日本で使用する場合の問題について（My daylife in virtualworld）

Android Dev Phone 1 をソフトバンクで使った場合のパケット料金

Android Dev Phone 1 に DoCoMo、Softbank、e-mobile の SIM を刺してみた

Android Dev Phone 1 到着、アクティベーション完了

blogger でタイトルを変更する

Dec 21, 2008

ブラウザのウィンドウ（タブ）に表示されるタイトル名が、blogger は長い。

<pre class="prettyprint">
collectivemeta: blogger でタイトルを変更する
</pre>
と出てしまうところを、
<pre class="prettyprint">
blogger でタイトルを変更する
</pre>
と短くまとめたい。


と思って検索したら、みな同じことをやりた

Android Dev Phone 1 をソフトバンクで使った場合のパケット料金

Dec 21, 2008

パケホーダイ全盛のこの世で馬鹿なことだとは思うが、初めてパケ死を経験した。Android Dev Phone 1 に iPhone 3G のソフトバンクの SIM を刺して使っていた。パケット定額フルが適用されるものと思っていたのだが、ソフトバンクから○万円超えてるよとの通知をもらって驚いた。定額分にカウントされず、PC から USB などでつないで、モデムとして携帯を使ったときの料金になっているというのだ。

瞬間的に思ったのは APN を iPhone 3G のものにしていないということ。そこで早速、APN を変えてみた。ただ、それで定額になるかどうかは、明日にならないと確認ができない。ソフトバンクでは、たとえユーザーサポートに電話しても、前日分までの料金しかわからない。さらに悪いことに、自動案内やWebからは確認できるのは、各種割引制度適用前の金額なので、サポートの人に電話をかけて直接聞くしか、行為の正しさを検証する方法がない。他の多くのユーザーサポートと同様に、ソフトバンクのサポートも、電話をかけると長時間待たされる。

サポートに電話をして正確な料金を聞いたついでに、いくつか尋ねてみた。マイナーな質問をしてしまったようで、1つ回答をもらうまでにえらく待たされる。相手をしてくれたお姉さん、ありがとう。

SIMロックフリー端末を使ってはいけないのか？: 音声通話もパケット通信も、使って頂いて構わない。ただ、期待する料金プランが適用されないことがある。
パケット定額フルが適用される場合と適用されない場合をユーザーはどう判断すればよいか？: ユーザーが自ら判断する方法はない。カタログやホームページには「一部機種の機能を利用した場合」は適用されないと記載している。
SIMロックフリーの iPhone 3G を利用した場合にもパケット定額フルは適用されないのか？: 適用されない。（マニュアルや裏の人に確認せずに回答していたので、本当かどうかはわからない。ここはもっと念を押して聞けば良かった）

本当は、APN のことも聞いてみたかったのだが、SIMロックという言葉の意味から説明しなければならなかったサポートの人にそれを聞けば、さらに待たされることが明らかだったので、あきらめた。そもそも非公開情報なので、簡単に答えてくれるとも思えない。

パケットの請求額は、ユーザーサポート様の配慮により、ある程度緩和された。パケット定額フルとは程遠い額ではあるけれども。

それ以上は頑張らなかったが、弁護士や右翼やその他交渉上手な人であれば、パケット定額フル料金にまで持っていけるような気がする。料金を手軽に確認する手段が存在せず、適用と非適用の境界も曖昧なので、消費者保護の観点からは褒められた仕組みになっていない。

ところで、APN を iPhone 3G のものにすればパケット定額フルが適用されるようになるのか？その結果は明日以降に判明する。いま、ソフトバンクの 3G ネットワークには、iPhone の負荷が相当にかかっていると言われる。そんな中で、インターネット接続が主であるようなSIMロックフリーの端末が自由に使えるようであれば、いずれその負担はユーザーに回ってくることになる。少なくとも現状のソフトバンクに限っていえば、共存共栄の関係にはなり難い。

ソフトバンクがダメであれば、DoCoMo の mopera U 定額データプランもある。もう少し実験してみようと思う。ただ、現状の Android は、普通に日本語入力が出来ないという点も含めて、常用端末にするのはちょっと厳しい。なので、メイン携帯の DoCoMo を置き換えるというのは躊躇してしまう。

そもそも開発用端末を常用しようというのが間違っているのかもしれないが、それでも、Android には iPhone と同じように夢を感じさせるものがある。未来をほんの少し先取り。そのワクワク感がいい。

Android Dev Phone 1 をソフトバンクで使った場合のパケット料金 2

Android Dev Phone 1 に DoCoMo、Softbank、e-mobile の SIM を刺してみた

Android Dev Phone 1 到着、アクティベーション完了

Android Dev Phone 1 に DoCoMo、Softbank、e-mobile の SIM を刺してみた

Dec 18, 2008

DoCoMo

つなごうとしてようやく判ったのだけど、mopera U などのパケット通信の契約が必要らしい。iモードとは別なので注意。たとえパケホーダイを契約していても、Android Dev Phone 1 のパケット通信料がそれでカバーされるわけではなく、別途インターネット接続サービス mopera U などののライトプランや定額プランの契約が必要。iモードのパケット通信と、携帯とPCを繋いでパケット通信をするときの接続先が異なるということなのだろう。

mopera U ライトプランをiモードから契約してユーザIDとパスワードを得た後、APNとして