要約：
LinuxのDRBDのようなネットワークミラーリングをWindows上で実現し、ノートPCのクローンマシンを常時維持しておけば、ノートPCを失った際のダメージが軽減される。
クローンマシンは、オリジナルマシンと同じ機種のノートPCである。クローンマシンはUSBメモリからクローン用の組み込みソフトを起動する。USBメモリを抜いて再起動するだけで、クローンマシンはオリジナルマシンになりかわることができる。
そもそもの始まりは、ゴールデンウィーク直前に、我が家に入っているKDDIの光ファイバーが鳥害で断線したことだった。ちなみにこの光ファイバーは、数年前にも同じ理由で断線している。こうして私はフレッツ光に乗り換えた。KDDIに三度アナテマ。
時期が悪かったのか、復旧はゴールデンウィーク後になるとの見通しだった。私はいつも自宅ですべての作業をしているが、回線が切れているのではどうしようもなく、某仕事先にノートPCを持っていくことになった。
さて、マーフィーの法則――失敗する可能性のあるものは必ず失敗する。この失敗とは本物の失敗であり、いつ失敗するかは指定できない。「ここで失敗してください」とか「ここでは失敗しないでください」と注文をつけても無駄だ。本当にこんな間抜けな注文をつける馬鹿がこの世には実在するから恐ろしい。「気をつけていれば大丈夫」だの「目を離さなければ大丈夫」だのがそれだ。まともな人間だと思われたければ、こういうことはけっして口にしてはいけない。
マーフィーの法則に従い、私は移動中の電車の中で、ノートPCを紛失した。断線の二次災害である。
仕事用のデータのほとんどはサーバ上にあったが、作業環境および一部のデータはこのノートPCにしかなかった。この二次災害の影響によりさらに三次災害が生じたが、災害のピタゴラ装置をお目にかけたいわけではないので、それはさておき。
私は後知恵で考えた――ノートPCの喪失にどのように備えるべきだったか？
「HDDのバックアップ」という答えは不十分すぎる。バックアップでどれだけダメージを軽減できるかは、運に大きく左右される。バックアップを毎週土曜の夜に取っていたら、土曜の午後にノートPCの喪失が起こるかもしれない。さらに、ほとんどの場合、リストアはオリジナルを喪失してから初めて行う。オリジナルと同じ機種が用意できず、異なるハードウェア上にリストアしてみたら、STOP 0x0000007B エラーが出て口から泡を吹くことになる。
運の要素を減らすには、ミラーリングが必要だ。
ノートPCの喪失に備えるからには、ミラーリング先はPCの外に設けることになる。ここで問題になるのは、ノートPCだから、常時ミラーリング先とつながっているわけではない、という点だ。ミラーリング先と切り離されているあいだにHDDに書き込まれたデータをバッファしておく必要がある（このデータのことを以下ではコミットログ、コミットログのために確保されている記憶領域をコミットログ領域と呼ぶ）。コミットログ領域が満杯になった場合には、バッファリングをあきらめて、フルコピーをスケジュールする必要もある。これは特殊なミラーリングだ。
幸い、この特殊なミラーリングをすでに実現しているソフトウェアがある。LinuxのDRBDがそれだ。ミラーリング先がWindowsである必要はない（むしろライセンス料を避けたい）ので、DRBDのオリジナル側だけをWindows上に実装すれば、望みどおりのミラーリングが実現できる。
これで運の要素は最小限に切り詰めたが、ミラーリング先となるPC、つまりサーバに類するマシンが必要になる、という問題が新たに発生する。そこで、ミラーリング先となるPCを、オリジナルと同じ機種のノートPCにすればいい。代替マシンの調達という問題も解決できる。
クローンマシン（ミラーリング先となるPC）ではLinuxを動かす必要がある。しかしHDDはオリジナルとクローンで同一内容なのだから、HDDにはインストールしたくない。そこでクローンマシンは、USBメモリからブートする。
オリジナルマシンでも、コミットログ領域はHDDからは取りたくない。これもUSBメモリ上に取ると都合がいい。
オリジナルマシンとクローンマシン、どちらにもUSBメモリを刺すことになる。では、この2つのUSBメモリをペアとして作れば、設定の手間が省ける。このUSBメモリペアを売れば、商売として成り立つだろう。つまり、こういう製品は存在しうる。
細かな点について。
クローンマシンは常時起動している必要はない。Wake On LANというものがある。
USBメモリはHDDより遅く、USBメモリにコミットログを書き込む以上はどうしてもパフォーマンスを損なう場合がある。ただし同期的に書き込む必要はないし、コミットログは常にシーケンシャルなので、大きなシーケンシャルライトだけが問題となる。
フルコピーの際にもオリジナルマシンを止める必要はない。XP以降ではボリューム シャドウ コピー サービスが使える。
DRBDはパフォーマンスや現実性のサンプルであり、必ずしも実際にDRBDを使う必要はない。
設計について。
オリジナル側は2つのコンポーネントからなる。
・ストレージクラスのフィルタドライバ
・サービス（Windowsのデーモン）
フィルタドライバはHDDへの書き込みを監視して、主記憶上にコミットログを書き込む。サービスは、
・コミットログの転送（主記憶またはUSBメモリから、クローンマシンまたはUSBメモリへ）
・コミットログ領域の残量を監視し、不足時にはフルコピーへと方針を転換する
・クローンマシンの制御（Wake On LANで起こす、ハードウェア障害の報告を受け取る等）
・フルコピー
などを行う。
技術的に面倒な点は、おそらく3つある。
・DRBDの把握。特に、パフォーマンスを出すための工夫
・カーネルモードドライバを書く
・ボリューム シャドウ コピー サービス関係。特に、フルコピー開始とコミットログのあいだで整合性を取ること
このアイディアを思いついた瞬間は、「コンセプト実証だけなら1ヶ月でやれる」と思い上がったが、よくよく検討してみると、ボリューム シャドウ コピー サービス関係がきな臭い。触る人の少ないところはヤバいと相場が決まっている。というわけで現在の見通しは、コンセプト実証に1年、ドッグフードまで2年。ぬーん。誰かかわりに作ってください。