JDSF | ストレージ管理ソリューション部会 | データ・ストレージに関する総合情報サイト

HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

リモート・デバイスとモバイル・デバイスのバックアップ

著者：W. Curtis Preston

Storage Magazine 2011年3号より

リモート・サイトのサーバーやモバイル・コンピューティング・デバイスをいかに適切にバックアップするのかという課題は、ずいぶん以前から議論されてきた。しかし、会社員のモバイル化が進行する今こそ、リモート・バックアップを征服すべきときだ。

リモート・データセンターとモバイル・ユーザーは、バックアップとリカバリーにとっての最後のフロンティアである。そのフロンティア精神は、多くの会社におけるリモート・データやモバイル・データのバックアップに対する、質素さに垣間見ることができる。リモート・データセンターは、ラップトップやその他のモバイル・デバイスも同様だが、「大」データセンターが最新のバックアップとリカバリー環境を享受している一方で、あまり顧みられることなく、貧弱な方法でバックアップとリカバリーを行っている（全く行っていないところもある）。しかし、メインのデータセンター以外のところで、大量のデータが生成され、運ばれている今こそ、変革の時だ。

問題の根源

リモート・データセンターでは、多くの場合、細い接続で本社バックアップシステムにつなげられたバックアップシステムが使われている。さらに、そこで扱うデータが一般的に小さめなため、リモートのセンターでは、メインのデータセンターに比べ、安価なソフトウェア、ハードウェアを使うことが多い。そのため、メインのデータセンターでは、エンタープライズ・クラスのバックアップ製品が大規模なターゲット型重複排除システム、あるいは、テープライブラリーにバックアップを行っている。その一方、リモート・データセンターでは、ワークグループ・クラスのバックアップ製品で小さなオートローダー、さらにはスタンドアローンのテープ・ドライブにバックアップを行う、というパターンが多い。
同様に、メインのデータセンターでは通常メディア保管会社と契約を結び、オフサイトにおける毎日のバックアップを確保している。さらに良いのは、メインのデータセンターで重複排除システムを使っていれば、オフサイトへのレプリケートは即座に行うことができる。ところが、リモート・データセンターとなると、バックアップシステムはろくに監視もされず、管理者がセンターから遠く離れた、出張先の車の後部座席から操作する、などということもままある。

モバイル・データのバックアップは、さらに酷い状況になっている。多くの会社は、モバイル・データのバックアップ・ポリシーを全く持たず、重要なデータはファイル・サーバーにコピーするように、という指示だけで済ませている。（替わりとなる適切な）可能なバックアップ・ポリシーを見つけず、問題を無視している。

普通のモバイル・コンピューター・ユーザーは、定期的に自分のバックアップを行うことなど考えもしない。さらには、モバイル・ユーザーに自分の大事なデータをファイル・サーバーと同期させておくように要求することは、ひとつの基本的な事実を無視している。彼らはモバイルであるがゆえに、サイズの大きいファイルや、サイズは小さいが数が多いファイルを同期するだけの帯域を持っていない可能性が非常に高い、ということだ。

今日の会社員の機動力（モビリティ）の増大を考えると、会社が知的財産と見なすデータの相当量が、データ保護がなされていないリモート・デバイス上にあるのだ。

「シード」と呼ばれる、リモート・コンピューターからの最初のバックアップは、リモート・データのバックアップを設計する上で、考慮に入れておかなければならない。極めて小さい容量（数ギガバイト）をバックアップしているのでなければ、メインのサイトにいかにしてシードを転送するかの方法を見つける必要がある。これは、一般的に、何らかのポータブルデバイスにバックアップをしてから、物理的にメインのサイトに運搬し、そこのバックアップ・サーバーにコピーする、という方法で行われる。オプションの検討のために、現在使っているバックアップ製品のベンダーが、この分野で提供しているオプションを確認することをお勧めする。

モバイルのバックアップはなぜ難しいのか

残念ながら、リモートおよびモバイルのバックアップ・データセットが、このようにでたらめに扱われてきたのには理由がある。問題の解決に取り組む前に、これらの理由を理解するのは重要な事だ。

リモートおよびモバイルのバックアップ・データセットが、メインのデータセンターのデータと同じように扱われなかった理由は明白である。それらが、メインのデータセンターにないからだ。リモート・サイトやユーザーと、メインのデータセンターを結ぶ低速接続は、遠隔のシステムではメインのデータセンターと同等のバックアップ・ソフトウェアは使えない、ということを意味する。これらのバックアップ・アプリケーションは、データセンター内のサーバーとの高速接続を前提としており、リモート・サーバーと話そうとすると、パフォーマンスが極めて貧弱になる傾向がある。帯域の制限によって大容量のデータ転送は妨げられ、レイテンシーが作り出す遅延によって、アプリケーションはサーバー・クライアント間で大量のパケットのやりとりを発生させる。

もうひとつ厄介な事は、バックアップされるコンピューターが、データセンターのサーバーと同じように四六時中電源がONになっているとは限らない、ということだ。ほとんどのラップトップユーザーは（そして、他のタイプのリモート・デバイスのユーザーも）、自分が使わないときはデバイスの電源を落とすか、スリープ状態にする。これほど顕著ではないが、リモート・データセンターのユーザーも、往々にしてサーバーやデスクトップPCに対して同様のことを行う。大問題、というほどでもないが、対処しなければならない問題だ。

次の難問は、前述の問題とまさに対極に位置する問題だ。ユーザーの中にはコンピューター、さらにはアプリケーションを24時間立ち上げたままにしておく人たちがいる。そのためリモート・バックアップを行うバックアップシステムは、オープンファイル（そしておそらくは交信中のファイル）に対処しなければならない。

最後に、ベアメタル・リカバリーの要件がある。メインのデータセンターでは、ハードウェアの一部が障害を起こしたとき、あらかじめイメージ・バックアップしておいたドライブに交換するなど、様々な代替策がある。しかし、リモートのユーザーにとっての最善の代替策は、それなりの速度のWAN接続を持ち、本社のIT部門の誰かがつかまることを望むこと、なのもしれない。リモートのサーバーかラップトップがオンサイト保守に入っていれば、ベンダーはハードディスクなり他の壊れた部品なりを交換してくれる。しかし、次に必要になるのは、極めて簡単なステップで実行できる、ある種の自動リカバリー（例：CDをインストールしてリブート、など）、である。

解決されたリモート・バックアップとモバイル・バックアップ

遠隔帯域の難問を解決するのに、現在、一般的に用いられている方法はブロック・レベルでのインクリメンタル・フォーエバー・バックアップ技術である。低速接続でのバックアップで重要なのは、すでに送ったデータを再び送らない、ということだ。フル・バックアップはもはやありえず、インクリメンタル・バックアップでさえもデータ転送量が大き過ぎる。新規で、固有のデータのみ、バックアップしなければならない。

レイテンシーは、また別の問題だ。ある製品がブロック・レベルのインクリメンタル・バックアップに対応しているからといって、それがリモート・アプリケーションとして設計されているとは限らない。そのバックアップ・ソフトウェアが、リモート接続で通信していることを理解し、いかなる時でも「ラウンドトリップ」を回避することを確認する必要がある。十分な帯域のリモート接続を持っていても、バックアップ・ソフトウェアが接続のレイテンシーへの対応をしていない場合、バックアップ・パフォーマンスは著しく低下する。

iPadユーザーは二つに分けられる。iPadをデータの閲覧用に使うユーザーと、iPadを使ってデータを作成したり修正したりするユーザーだ。最初のカテゴリーのユーザーについては心配しなくても良い。二番目のグループ、――活動的で、実際に情報を作成し、修正する人々――に対しては、iPadをいかにバックアップするかを教える必要がある。これを最も簡単に行う方法は、ユーザーが自分のラップトップやデスクトップPCと同期を取り、iPadがバックアップされたか確認することだ。これは完璧な方法とは言えないが、iPadのアーキテクチャを考えると、今我々が取りうる最善の方法だろう。一番厄介なのは、各アプリケーションが、それぞれに独自のスペースを持っているところだ。インターネット越しに遠隔でデータをバックアップできるアプリケーションでも、データが作られ、修正されているファイル・スペースにアクセスできるとは限らないからだ。

重複排除で全て解決

これらの問題の多くを解決するために、多数のユーザーに採用されている技術が、データ重複排除である。この技術により、転送しなければならないデータの量は大幅に減る。重複排除システムは、様々な場所に存在するデータの情報を持っているので、個々のリモート・サーバーやモバイル・デバイスにとって新規に書かれたデータ、というだけでは、バックアップを行わない。システム全体とって新規のデータのみをバックアップする。つまり、あるファイルが1台のラップトップからすでにバックアップされていた場合、同じファイルがもう1台のラップトップに存在していても、このファイルの2番目のインスタンスはバックアップされることはない。

重複排除には、大きく分けて二つのタイプがある。ターゲット型重複排除（アプライアンス）とソース型重複排除（ソフトウェア）だ。ターゲット型重複排除のアプライアンスは、テープの替わりに既存のディスクを使うように設計されており、バックアップ・ソフトウェアはバックアップ・データをアプライアンスに送り、そこで重複データは除かれて新規で固有のブロックのみが保存される。重複排除のアプライアンスには、もうひとつ利点がある。バックアップの一次ターゲットをディスクからテープに替えることにより、リモート・サイトのバックアップの信頼性向上が望める点だ。

ターゲット型重複排除を使うためには、各リモート・サイトに1台ずつアプライアンスを設置し、そこに直接バックアップしなければならない。アプライアンスが、一つのリモート・サイトのバックアップ・データの重複排除処理を終えると、そのアプライアンスとメインのサイトとのレプリケーションが可能になる。ターゲット型重複排除は、何かしらのアプライアンスを必要とするため、モバイル・データのバックアップには向いていない。

ソース型重複排除は、バックアップ処理の最初の段階においてデータの重複を排除するバックアップ・ソフトウェアである。バックアップ対象のサーバーやモバイル・デバイスは、ソース型重複排除サーバーと通信を行い、バックアップが必要であると判断したデータ・セグメントを「報告する」。ソース型重複排除サーバー側で、そのセグメントがすでにバックアップされているものだと分かれば、データはネットワーク越しに転送されない。これは、重複排除サーバーのディスク・スペースの節約になり、バックアップ処理が使用するネットワーク帯域の削減もなる。

ソース型重複排除は、リモート・サイトでも、モバイル・ユーザーでもバックアップの用途で使うことができる。やることは、バックアップ対象のコンピューターに、ソース型重複排除をインストールして、バックアップを始めるだけだ。（言うまでもなく、多少、単純化して書いている。最初のフル・バックアップをどう行うか、という難題は素通りしている。）

リモート・データの継続的バックアップ

リモート・サイトとモバイル・ユーザーのバックアップで考慮すべきもう一つの技術が、継続的データ保護（CDP）である。CDPを「戻る」ボタンつきのレプリケーションと考えて欲しい。レプリケーションと同様、プロセスは一日中実行され、差分として新規ブロックがリモートのバックアップ・サーバーに転送される。しかし、標準的なレプリケーション製品と違い、CDP製品ではログも同時に保存している。そのため、保護対象となっているシステムは、数秒またはそれ以下の戻し時間で、過去のどの時点にでも戻ることができる。従来のバックアップシステムが（重複排除を使っているものも含め）、対象となるクライアントを、最後にバックアップが実行された時点に戻すのに対して、バックアップを継続的に取っているCDPは、クライアントを数秒前の時点に戻すことができる。CDP製品もまた、ブロック・レベルのインクリメンタル・フォーエバー技術に基づいており、リモート・サイトでもモバイル・ユーザーでも使えるものになっている。

統合データ保護

リモート・サイトにはもう一つの選択肢がある。時として、自己修復ストレージ、と呼ばれるものを使う方法だ。この用語は広義には、基本機能としてバックアップとリカバリーを持っているストレージを指す。一般的には、保護対象のボリュームでブロックとファイルの履歴を取るために、リダイレクトオンライト・スナップショット技術を使っているストレージ、として説明される。このスナップショットは、次に、（一般的には待機系システムが置かれている）別なボリュームにレプリケートを行い、従来型のバックアップ方法を使うことなく、データ履歴の保存と再配置を実現している。これらの製品を使ってリモート・サイトにバックアップするには、当然、メイン・サイトより大きなストレージにレプリケートするストレージを各リモート・サイトに1台ずつ配備する必要がある。

クラウドはどうか？

クラウドバックアップは、上述のいずれかの選択肢を提供している、もう一つの方法である。あるクラウド・バックアップ・サービスでは、ソース型重複排除を使っているし、別なサービスではCDPを使っている。また、あるサービスでは、オンサイトのターゲット・アプライアンスを提供し、そのアプライアンスからクラウドへのレプリケーションや、そのアプライアンスをターゲットとして、ユーザーの重複排除アプライアンスからのバックアップを行っている。ある種の自己修復ストレージは、クラウドに対してもレプリケートを行う機能を持っている。

ベアメタル・リカバリーの問題は、バックアップ・ソフトウェア製品、または、その製品が組み込まれたサービスによってのみ、解決される問題である。自社の環境で、この機能がどれだけ重要なのか、慎重に検討してもらいたい。そして、ITの他の事柄と同様に、ベンダーの言うことを鵜呑みにしてはならない。本当に自社のニーズに合っているかどうか、その製品、あるいはそのサービスをテストしてもらいたい。

電源が常時ONになっているとは限らないシステム、いつもWANが繋がっているとは限らないシステムのバックアップを、ベンダーの製品がどう対処しているのか、是非聞いてみるべきだ。ほとんどの製品やサービスが、これらの課題に対応しているとはいえ、その対応方法は時として、ユーザーの使用状況に重大な影響を与えることがある。例えば、長時間インターネットに繋がっていなかったラップトップが、やっとインターネットに繋がった、としよう。バックアップ製品は、長時間未処理になっていたバックアップを開始する。ここまでは、良い機能に思えるだろう。しかし、バックアップは、ラップトップで使用可能なすべてのリソースを消費するかもしれない。次に起こるのは、ヘルプデスクへの電話か、他の業務を妨害するバックアップ・プロセスをユーザーが停止するか、だ。様々な条件のもとで、バックアップを行ったときに、バックアップ・アプリケーションがシステムにどれだけの負荷が掛かるのか、十分に確認しておいて頂きたい。

著者略歴：W. Curtis Prestonは独立のコンサルタント、ライター、講師。現在はサーバー管理と仮想化を集中的に取り上げている。BackupCentral.comのウェブマスター兼Truth in IT Inc.の創業者。

ストレージ・マガジンはエンタープライズITにフォーカスしたTechTargetポートフォリオの一つです。