災害や停電に備えたディザスタリカバリや、BCP（事業継続計画）のための遠隔地のサーバーへのデータレプリケーションも、オープンソースのDRBDで実現できる。WindowsなどLinux以外のサーバーのデータをバックアップすることも可能だ。
DRBDによる遠隔レプリケーション
ディザスタリカバリは、被災からの被害の軽減や復旧と、それを可能にするための日常的な取り組みといった総合的な取り組みである。コンピュータシステムの場合、データを喪失しないように保全することが出発点となる。
バックアップしたテープを別事業所や保管業者に預けるのが一般的だ。ディザスタリカバリサイト（以下DRサイト）のサーバーに定期的にバックアップする方式もある。しかしメインサイトのサーバーが壊れたら、最後のバックアップ時点以降のデータは失われてしまう。最も理想的なのは、メインサイトとディザスタリカバリサイト（以下DRサイト）の間でデータをレプリケートすることだが、これまでは導入コストや運用コストが高く、適用対象が限られていた。
DRBDはローコストに遠隔レプリケーションを実現できる。TCPを使ってレプリケートするため、原理的に距離の制約はない。LAN環境でのレプリケーションと、設定も運用も変わらない。オープンソースなのでライセンス料や保守料は不要だ。
最もシンプルな構成は、メインサイトとDRサイトにそれぞれ1台のサーバーを置き、データ領域同士をDRBDでレプリケーションするという構成だ。メインサイト側サーバーでデータの書き込みが発生すると、DRサイトのディスクの同じ位置に同じデータが書き込まれる。
メインサイトのサーバーが被災で壊れた場合でも、DRサイトに被災直前までのデータが残る。DRサイト側でサービスを起動できるようにしておけば、サービス自体を早期に再開することも可能だ。
ただし、DRBDは元々はLAN環境での利用を想定して、できるだけ軽く動作するように作られている。パケット圧縮やパケット暗号化には対応していない。帯域幅に制限がある場合、あるいは盗聴対策などのセキュリティ対応は、DRBD単体では限界がある。
WANの特性を考慮する
リモートレプリケーションを実現するには、専用線、IP-VPN、インターネットVPNなどのWAN回線を使う必要がある。ディザスタリカバリにギガビットクラスの専用線を確保できるケースはきわめて限られ、一般的にはベストエフォートのファイバ回線を使うケースが多いと思われる。このクラスの回線には、LANと比較して次のような制約がある。
・使用料は帯域幅に依存するので、一般にLANよりも狭い帯域幅に制限される
・レイテンシ（遅延）が大きい。LANの場合ミリ秒以下が普通だが、WANでは数ミリ秒～数百ミリ秒になる
・サービス種別によってはメンテナンスなどで接続が切れることがある
・サービス種別によっては転送量を制限されることがある
最大50ギガバイト/日のディスクデータが書き換えられるシステムの場合、平均的に約6Mbpsの帯域幅が必要になる。時間帯によるバラツキを考慮すると、この2～3倍程度の帯域幅は確保したい。
DRBDのオプション製品であるDRBD Proxy（有償ソフト）を使うと、パケット圧縮とバッファ機能によって、これらの制約を緩和または解消できる。経験的に、テキストデータ主体のデータベースやオフィス文書主体のファイルサーバーなどのデータは約半分程度に圧縮できることが多いためだ。なおDRBD Proxyはパケット暗号化には対応していないため、必要ならばSSHトンネリングやIPsecなどと組み合わせることになる。
なお、転送量制限に関しては、複数のWAN回線を束ねて1本のラインとして扱えるようにする、回線集約装置が効果的かもしれない。
