Jeff Atwood氏は、最近２つのブログサイトを失った: Blog @ Stackoverflow と Coding Horror。彼は、なんとか両方のwebサイトを回復させたが、この事件から学ぶべき教訓は、何だろうか？
氏は、なぜそしてどのように、サイトのコンテントをバックアップすべきかについて、 ２００８年１月の記事に載せている:
一つ確かなのは：ある種のバックアップ戦略を持つまで、すっかり騙せれ、それを知らないだけである。もしデータのバックアップをとることが、面倒なことのように聞こえたら、実際にそうだからである。 黙れ。私はわかっているのだ。ただ、黙ってきけ。とにかく、やるのだ。
氏は、Stackoverflowのブログと Coding Horrorのバックアップ戦略を持っていた、また両サイトは、 CrystalTechによってホストされていたが、定期的にサイト全体がバックアップされていた。それでは、webサイトの中身をどうやって失ったのか？webサイトは、仮想マシン(VM)の中でホストされていて、CrystalTechは、VMのイメージをバックアップしていた。しかしそのイメージは、実際、破損していた。そのため、バックアップされたものには、何の役にもたたない、多くの破損したVMイメージがあった。VMを、それから立ち上げることはできなかった。最初、氏は、自分とホスト側をとがめた:
Jeff Atwood: あー、CrystalTechのサーバの故障だ。明らかに、通常のバックアップ プロセスが、VMイメージをバックアップする時に、何事もないかのように、失敗している。
Jeff Atwood: はっきり言って、私は、半分ホストしているプロバイダをあと半分自分をせめた（ホスティング・プロバイダを信じないで、自分のオフサイトのバックアップもすることだ！）
何人かのユーザの助けにより、氏は、なんとか ブログの失ったコンテンツを回復した。Rich Skrenta氏が、文書を回復するのを助けた。:
blekko.comのRich Skrenta氏のおかげで、私は、ほとんどすぐに、Coding Horrorの静的なHTML版を入手できました。彼は、親切にもサイトのリンクした全ページの圧縮ファイルをくれました。ある人達には、目標があります。また、ある人々には、 大きく困難で大胆な目標があります。Rich氏のは、特に驚嘆させます：サーチのホーム・グラウンドでグーグルに挑戦しているのですから。だから彼は、たまたまCoding Horrorの完全なテキストのアーカイブを持っていたのです。Rich、 あなたは、私のヒーローだっていいましたっけ？ とにかく、Richのお陰で、あなたは、今、Coding Horrorの静的HTML版を見ているのです。驚くべきことに、このサイトの静的HTML版とライブサイトとの差は、大きなものではありません。最小主義者であることの恩恵の一つだ、と思います。
一方、イメージは、Carmine Paolino氏からもらいました、氏は、たまたま “サイトをバックアップしたほぼ完全なミラーを彼のMac上に持っていました。彼のミラーのお陰で、ほぼ１００％失ったイメージとコンテンツを回復しました” 。サイトを回復し、再び生き返って、Jeff氏は、最後に自分を責めた:
私は、大馬鹿だったので、Coding Horrorの自分の（最近の）バックアップを持ってませんでした。ああ、 バックアップ戦略についての良いブログ記事を読んでいたらな!と思います。
彼は、こう結論した:
この悲しい出来事から皆が学べることは？
- 私は、最低。
- いや、本当に最低。
- 自分の大事なデータをバックアップするのに、ホストや他人を頼るな。自分でやれ。自分のバックアップに、もし個人的に責任がなければ、 実際上、問題とはならない。
- もし本当に悪いことが、データに起こったなら、どうやって回復したらいいのか？そのプロセスは？回復するのに難しい部分は、何か？一番難しいのは、テキストだと思い続けていたので、Coding Horrorの回復シナリオについて誤った自信を持っていた、と心の奥で思っています。もちろんテキストは、一番簡単なところだと、分かりました。 "持つといいもの"と考えていた、イメージは、本質的に、回復が非常に難しいと認識しました。 我々は、 "バックアップ "についてではなく回復することについて話すべきだ、という人もいます。
- 定期的に、自分の回復プロセスが、ちゃんと動いていて、完全に機能していることを確認すべきです。
- 私は、すばらしい。いや、冗談。私は、最低です。
Joel Spolsky 氏は、修復が確認されず、 バックアップ戦略がうまくいいっていない 可能性のある、他のいくつかの状況をあげた:
- バックアップ ファイルが暗号的に安全なキーで暗号化されていて、そのキーのコピーが消失したマシンにあった
- サーバには、ものすごい量の設定情報があり、それらはバックアップされていないIISのメタベースに保存されている
- バックアップ ファイルがFATのパーティションにコピーされていて、何の警告もなく２GBを超えた分を失う
- バックアップがデータセンタで消失したLTOドライブにあり、３日間別のLTOドライブを入手できない
- “バックアップ” “を持っていて”も他のたくさんことが、うまくいかない
信頼できるサービスの最低限のことは、バックアップをとっていることではなく、修復できることです。もしあなたが、webサービスを運営しているのであれば、元のデータセンタにあったものには、アクセスせずに新しいサーバあるいはサーバ群上に、納得できる時間内に、サイト全体の納得いくぐらい最新のコピーを構築できることを私に示す必要があります。問題は、修復できたかどうかです。
人々にバックアップしていることを問うのはやめて、修復できているかを問い始めよう。
Jeff氏は、万が一に備えて、ブログサイトをStackoverflowをホストしているデータセンタに移した。そこでは、そこにある他のサーバも、もっと信頼性が高く、もっと良い バックアップ戦略を持っている:
- 全データベースの完全なバックアップを4 AM, 4 PM, と 12 AMにとる（あるデータベースはもっと積極的にバックアップする、しかしこれが典型的なもの。）これらの完全なデータのバックアップは、PEAKデータセンタのラックにある NAS RAID-6デバイスにストアされる。
- データベースのサーバには５００GBのUSBハードディスクが取り付けられている。C#で書かれたスクリプトにより、NASからUSBハードディスクに毎夜１AM頃に最新バックアップがコピーされる。必要に応じて、最も古いファイルは、消されて、新しいファイル用の空きをつくる。（現在のStack Overflowの完全なバックアップは、圧縮して約７GB、そして他のデータベースは、おそらく圧縮して２GBである。）新しいこと：２台のUSBハードディスクを取り付けていて、並行に全く同じコピーをして、両方のうち１台に問題があった場合に備えている。
- 我々のチームメンバの Geoff Dalgas氏は、PEAKデータセンタから１マイル離れたところに住んでいる。彼は、数週間毎にそこに寄って、USBハードディスクを物理的に交換する。彼は、家に４台の５００GBのUSBドライブを持っていて、データセンタに他の２台がある。それらが長い期間をかけて順番に交代する。
- 新しいこと：Fog Creek氏は、FTPを使って、最新のデータベースのバックアップをホストする施設に毎週、土曜日の低トラフィックの時間帯に転送している。
- 我々は、毎月、全サイト（Stack Overflow, Server Fault, Super User）の Creative Commons でデータダンプしている。これは、データの一部であるが、かなりの大きさで、 Legal Torrentsで入手できる。これらのデータのダンプは、物理的に Legal Torrentsにホストされ、またLegal Torrentsよって消される。
- 我々のSubversionのソース管理レポジトリは、毎日NASにコピーされ、同じ筋書きで、外部ドライブなどにもコピーされる。
- ２，３のVMイメージも走らせている。 — Linuxのヘルパーサービスとして、たいていは — そして同じプロセスで、VMイメージは、バックアップされる。我々の他のホストが、その難しさを知ったように、動いているVMイメージをバックアップするのは、扱いにくいものとなるので、これは、確かに慎重になる必要のあるものだ。
- 我々は、定期的に最新のバックアップをダウンロードし、それらをローカルにリストアして（我々は、ひっきりなしにやって、生データと変わらないぐらいに近づいている）、それで我々のバックアップがうまくいっているのがわかる。
この戦略は、最初に作った仕組みよりもずっと良いように聞こえる。この場合の弱点は、 “Geoff”である。もしGeoff氏がドライブの交換に現れなかったら？あるいは、彼がドライブを落としたら？あるいは、泥棒が、彼の家からドライブを盗んだら？
Jeff Atwood氏は、本当には責められない。誰にも起きうることだ、たとえもっといいバックアップ戦略をあったにせよ。重要なのは、このことから学ぶことができる教訓は、何だということである？