クラウドとバックアップ・アプリケーションの統合

バックアップ・アプリケーションは今日、ますます進化して洗練され、クラウド・ストレージもよりシンプルになって拡張性を高めている。しかし、まだいくつか解決しなければならない欠点もある。

皆さんは今でも、テープやディスク、あるいは重複排除ディスクでもいいが、そのような古めかしい媒体にバックアップを取っているのだろうか？　そうした場合に、容量の際限がなく、管理の必要もない媒体が利用できるとしたらどうだろう？　それがクラウドを利用したバックアップの利点だ。しかし、そんなに簡単にできるのだろうか？

クラウドといううたい文句を冠して宣伝されている製品やサービスは数多くある。だれもがクラウドの波に乗りたがっているし、人それぞれに、クラウドとはどういうもので、どういうことはできないか、考えがあるようにも見える。そこで、クラウドに関して、これという定義がない状況を踏まえて、今日はここでクラウドとは何かという議論をしてみたい。

クラウド――より厳密に言うとパブリック・クラウド――は、ユーザが管理する必要のないストレージ（バックアップ）だ。パブリック・クラウドは、オンデマンドで無限の容量を持ち、計り知れない機能を備えている。しかも利用料は、自分でストレージシステムを所有するのと同等か、それより安い。もし、今月は100テラバイト必要だけれども、来年は5テラバイトだけでいい、という場合には、そうした利用もできる。自分でストレージシステムを購入した場合、そのような柔軟性はとうてい期待できないだろう。というのは、使うと使わざるとに関わらず、システムの料金は支払わなければならないからだ。

これとは別に、プライベート・クラウドというのもある。こちらは、宣伝文句の大半が誇張だ。したがって、ここでは当初の目的に沿って、議論はパブリック・クラウドに絞ることにする。

クラウド・ストレージ vs. クラウド・バックアップ

クラウド・ストレージと、クラウド・バックアップという語は、混同して使われることも多いが、両者のあいだには明らかな違いがある。クラウド・ストレージは、サービスとしてのストレージだ。クラウド・ストレージを利用する場合には、サービスプロバイダでアカウントを取得し、APIの提供を受けてから、何らかのソフトウェアを使って、そのAPI経由でデータを保存する。あら、簡単！　これで、容量無限のストレージが利用できるというわけだ。データを保存したストレージを管理する必要もない。容量の追加を申し込む必要すらない。ユーザがしなければならないのは、料金の支払いだけだ。クラウド・ストレージのプロバイダはすべて、「ストレージ料」を徴収している。これは、自分のアカウントに何ギガバイトのデータを保存したかに応じて、月額制で支払うものだ。また、「帯域利用料」と称して、ダウンロード、あるいはアップロードしたデータ容量に応じて料金を徴収するプロバイダもある。ただ、クラウド・ストレージを利用する場合でも、そのクラウドにデータを送信するために使うアプリケーションは、自分で管理しなければならない。

一方、クラウド・バックアップをサービスとするには、サービスのプロバイダは、上記すべてに加えて、バックアップを実現するソフトウェアを提供しなければならない。クラウド・バックアップ・サービスでは通常、ある種のソフトウェアを提供して、これをバックアップを取りたいすべてのシステムにインストールしてもらう。そうすれば、あとは決められたスケジュールに沿って、プロバイダが自動的にバックアップを取ってくれる仕組みだ。バックアップ・ソフトウェアは通常、デルタレベル（増分：インクリメンタル）のバックアップ、もしくは完全な重複排除などの手法を用いて、ネットワークのトラフィックを最小限に抑えている。

何か不具合が生じた場合どのように対処してもらえるかは、プロバイダのサービスレベル契約（および料金）によって異なる。最低レベルの契約の場合、スクリーンに通知がポップアップ表示されるか、メールで通知が来て、サービスが滞りなく実施されている（か否か）が伝えられるだけの場合もあるだろう。また、バックアップに失敗した場合に、問題が解消されなければ、自動的にエラー解決の処理をしてくれるサービスもあるだろう

従来のバックアップ・ソフトウェアとクラウドの融合

自社のバックアップ・サービスで全面的にクラウドを使用している企業もあれば、従来のバックアップ手法とクラウド・サービスを組み合わせて、ユーザが選択できるようにしている企業もあるようだ。また、従来のバックアップ・ソフトウェアとクラウドの組み合わせ方も2通りあって、それらはコンセプトが大きく異なっている。その2つの方法を紹介すると、1つは従来方式とクラウド利用方式の両バックアップ・システムを並行して使用するやり方で、もう1つは、クラウドのストレージシステムをターゲットとして利用できる機能を備えたバックアップ・ソフトウェアを使用するやり方だ。

もし、「手間を省きたい」というのが最大の理由でクラウドのバックアップ利用を考えているのであれば、次の手順に従ってクラウドに移行するとよい。当面は、従来のバックアップ・ソフトウェアを使って、大半のバックアップをする。そのあと、クラウドのバックアップ・ソフトウェアを使用し、最もメリットの大きな部分のバックアップをする。標準的な手続きで言えば、遠隔地のデータやノートPCのデータから、クラウドのバックアップ・サービス利用を始めることになるだろう。ノートPCのバックアップは、まだ多くの企業が実施していない。するにしても、ノートPCのバックアップを従来のバックアップ・ソフトウェアで行うのは、控えめに言っても問題が多い。一方、遠隔地のデータのバックアップは大半の企業が実施しているが、そうしたリモートのオフィスには、専門のITスタッフがいないため、理想どおりの方法が使えないことが多い。そうした場合に、クラウドのバックアップ・サービスなら、ノートPCやリモート・オフィスの問題を同時に解決でき、企業に残された仕事は、請求書の処理だけとなる。

クラウド・ストレージを従来のバックアップ・ソフトウェアのターゲットとして用いる場合、さらに問題も多いが、利点がないわけではない。つまり、従来のデータ用のクラウド・ストレージについて言えることは、バックアップ用のクラウド・ストレージについても言えるわけで、管理無用、無限の容量など、さまざまな利点もある。そこにさらに、多くの企業にとって悩みの種となっている、リモートのバックアップが自動で取れるという「ボーナス」が加わる。

しかし、クラウド・ストレージを、完全に従来のバックアップに取って代わる代替手段として使うとなると、利点より問題点のほうが多くなるかもしれない。

クラウド利用に関するデータ量の問題

第1の問題点は、従来のバックアップは大量のデータをストレージに送って保存するものだということだ。通常のバックアップ・システムでは一般に、週に1回完全バックアップを行う。また、（IBMのTivoli Storage Managerなど）ファイルシステム上での完全バックアップは反復して行わないバックアップ・アプリケーションでも、アプリケーション上では完全バックアップを行っている（非常に重要な一部のアプリケーションのデータについては、毎日、完全バックアップを行っている企業も多い）。さらに、従来型のものは、どのバックアップ・アプリケーションでも必ず、ファイル全体に対して差分バックアップを行う。ということは、変更されたのは、ファイルのなかのたった1バイトだったとしても、あるいは更新日時が変更されただけとか、アーカイブビットが立てられただけの場合でも、夜間のバックアップは全ファイルを対象に行われてしまう。

このようなやり方だと、ネットワークを介して大量のデータがターゲットのデバイスに送られ、そこに保存されることになる。このやり方で、ターゲット・デバイスがバックアップ・サービスのクラウドだったりしたら、とんでもなく広い帯域幅が必要になり、クラウドでのデータ保管料も驚くような高額になってしまうに違いない。データ重複排除の技術が開発されたのは、従来のバックアップ・システムにこうした難点が存在するためだったことを思い出してほしい。バックアップ・アプリケーションでは、プライマリディスクの1GBに対して、20GBの「テープ」を作成する。したがって、データセンターの容量が10TBなら、毎月約200TB分のクラウド・ストレージ料を支払わなければならない計算になる。

また、クラウド・ストレージのベンダを利用する場合、使用したディスク容量と転送したデータ量に応じて課される料金だけでなく、ベンダのクラウドにデータを送るための帯域の利用料も必要になってくる。したがって、常時10TBの完全バックアップを定期的に行い、それを接続先のサービスに送りたい場合、クラウド・ストレージのベンダを利用するのは実用的ではない。また、バックアップのニーズがそれほど高くない場合でも、従来のようなバックアップ方式だと、クラウドにはかなりの額のバックアップ・システム料がかかることになるだろう。

クラウドをオフサイトのデータ保存に利用するのは両刃の剣

第2の問題点は、皮肉なことに、クラウドのバックアップ・サービスを利用した場合の大きな利点に関係している。それは、遠隔地にバックアップ・データを保存するということだ。この手法で、まずはオフサイトにデータがあるという問題を解決するとしよう。しかし今度は、自社のサーバではなく、別の場所にすべてのデータがある、という問題が浮上するのではないだろうか？　これだと明らかに、復旧時間目標（RTO）を達成する能力が妨げられてしまう可能性がある。つまり、クラウドに保存されているデータのコピーは、そのものずばり、コピーでしかないということだ。もっとわかりやすく言うと、通常のデータリカバリで、コピーに頼ってはいけないということだ。インターネットを介して転送しなければならないクラウド・ストレージを、大量のデータの唯一のコピーの保存場所とするのは、単純に言って、災難を呼び込むようなものだ。

これは、データの重複排除にとっても頭の痛い問題のように思えるだろう。そのとおり。市場には、インターネットを介してデータを送る前に、データの重複排除ができるバックアップ・ソフトウェア・パッケージが数多く出回っている。この手法で、クラウド・ストレージにバックアップを取る場合の難点は克服できる。しかし、これではデータを取り戻すときの問題は解決しない。したがって、重複排除ができてもできなくても、クラウドに保存したデータのバックアップ・コピーを、何かのときに信頼する唯一のリソースにしないというルールを適用するべきだ。

クラウドへの接続をサポートするバックアップ・アプリケーション

現在は、数多くの企業がクラウドへのバックアップをサポートするソフトウェア製品やハードウェア製品をリリースしている。クラウドのサポートを最初に発表したバックアップ・アプリケーションのベンダはZmandaだった。オープンソースのバックアップ・プログラムAmandaを提供している営利企業である。Amanda Enterprise 3.1を利用すれば、Amazon.comのクラウド・ストレージ・サービスSimple Storage Service（S3）に直接バックアップ・データを保存できる。

CommVaultのSimpanaは、Representational State Transfer（REST）プロトコルをサポートしているベンダであれば、ベンダを問わずクラウドへのバックアップをサポートしている。したがって、CommVaultのSimpanaでは、Amazon.comやIron Mountain、マイクロソフトのAzure、Nirvanix、Rackspaceなどのクラウド・ストレージ・サービスを、バックアップあるいはアーカイブのターゲットとして利用できる。アーカイバは、反復完全バックアップを行わず、オブジェクトレベルでの重複排除機能を組み込んでいるため、クラウド・ストレージ用のデータ保護アプリケーションとしては、アーカイビングのほうが実用に適しているもしれない。

EMCおよびSymantecも、自社のネットワークにバックアップの機能を追加して、同様のサービスを展開している。EMCのNetWorkerは、同社のEMC Atmosをベースにしたストレージを利用して、クラウド・ベンダを問わないバックアップ・サービスを提供し、一方のSymantecは、Symantec Backup ExecでSymantec Protection Networkへのバックアップ・サービスを展開している。

使用しているバックアップ・アプリケーションがクラウドへのバックアップをサポートしていないタイプの場合は、クラウド・ストレージへのNFS/CIFS NASゲートウェイを提供しているNasuniのFilerの使用を検討してみるといい。標準レベル以上のバックアップ・ソフトウェアならどれでも、NFSあるいはCIFSマウントへのバックアップができる利点がある。

多少の難点はあるものの、クラウドと統合したバックアップ・アプリケーションを求めている場合は、データの重複排除が可能なものを考えてみるといいだろう。EMCのNetWorkerもAmandaも、製品に重複排除機能は組み込まれていない。CommVaultのSimpanaおよびSymantec Backup Execは、バックアップ・ターゲットにデータを送る前に、重複排除を行う機能がある。Simpanaに付属するのはターゲット型重複排除機能で、メディアエージェント（バックアップサーバ）にデータが送られてから重複排除を行う。これに対してBackup Execの重複排除機能はソース型で、クライアントサイドで重複排除を行ってから、データをネットワークに送信する。クラウド・ストレージを利用する場合、これはかなりうれしい機能だ。IBMのTivoli Storage Manager（TSM）もまた、重複排除機能を組み込んでいるため、Nasuniとの併用でなかなか魅力的な選択肢となる。

とにかく使ってみて、テストしてみる

クラウドのバックアップ・サービスは、従来のバックアップ・システムを補完するものと位置づけることができ、これらのシステムがある程度統合されていれば、さらにその価値は高まる。ハードウェアがオンサイトに設置されていれば、クラウドのバックアップ・サービスを利用するために必要なリソースはほとんどないため、実際のデータを使っての概念検証も比較的容易にできる。サービス導入に際しては、ライセンス料など少なからぬ投資が必要な上、バックアップ環境にも大きな影響を与えるので、これは非常に重要な点だ。バックアップ製品やサービスを利用する場合、すべてを必ずテストし、自分の目で確かめるまで何も信用しないこと。これが必要不可欠だ。

著者略歴：W. Curtis Prestonは、TechTargetのStorage Media Group編集主幹で、独立系バックアップ専門家でもある。データの重複排除をはじめとする、データ量削減システムについて特に造詣が深い。

All Rights Reserved, Copyright 2000 - 2010, TechTarget

*この翻訳記事の翻訳著作権はJDSFが所有しています。
このページに掲載されている記事・写真・図表などの無断転載を禁じます。