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

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

今日、最先端のバックアップはデータセンターなどのように「常に稼動」している現場の要求に応えようとしている。データはリアルタイムの保護と瞬時のリカバリーが求められる。さらにデータの保管期間も長期化の一途を辿っている。数年前であれば、これらの要求を満たすのはとても不可能に思えたが、今ではこの課題を解決するデータ保護技術やバックアップ・アプリケーションが出てきた。

訳註：*今回の翻訳ではこの段落と一部の章（章題の後に要約と明記した章）を要約しています。

リアルタイム・バックアップ

（要約）
「バックアップが問題なのではない。リカバリーが問題なのだ」という業界のフレーズがあるが、実際はバックアップをしなければリカバリーはできない。今日のデータセンターにおいてバックアップは頻繁に取る必要があり、それに対してベンダーは様々な方法を提供してきた。

ブロックレベル保護

（要約）
従来のファイルレベルの増分バックアップに比べ、ブロックレベルの増分バックアップはバックアップするデータ量も少なく、時間も短くてすむ。数年前から販売されていたが、最近機能が安定してきた。OracleやVMwareなどのアプリケーション・ベンダーはこの機能のためのAPIを提供している。この技術を使えば15分おきにバックアップが取れる。

15分未満のバックアップ・ウィンドウ

（要約）
データ保護ベンダーは、データ保護のウィンドウを15分よりもさらに縮めるべく、レプリケーションとバックアップの統合を行っている。具体的には、レプリケーションされたデータをバックアップソフトが自動的に２次ストレージにバックアップするものである。
リカバリー時にアプリケーションを２次ストレージに向けることで、ほぼ即時リカバリーができるようになった。

スナップショット統合

（要約）
最近のバックアップは、稼動系ストレージとの連携を深めている。バックアップ・アプリケーションから直接、稼動系ストレージのスナップショットを起動可能な製品もある。また、ユーザーが「xyz.doc」を検索すると、スナップショットとバックアップ・データの両方が、高速にリストアできる順に表示される。
スナップショットとレプリケーションをバックアップ・アプリケーションからコントロールすることによって、スナップショットをトリガーに、ローカルおよびDRセンターにデータをレプリケートする。それにより、ローカルサーバまたはデータセンター全体の障害に対して、完全なデータ保護と高速リカバリーを実現できる。

バックアップサーバー無しでのバックアップ

稼動系ストレージとの統合により、バックアップサーバーが不要になるケースもある。これにより、OracleやMS-SQLなどのアプリケーションを直接バックアップ（データ保護用？）ストレージにバックアップすることや、プライマリ・ストレージシステムからプライベートパス経由でバックアップデバイスにバックアップすることができるようになった。
この方法では多くの場合、バックアップ・プロセスはアプリケーション・オーナーに委ねられる。アプリケーション・オーナーはどのデータがどれくらいの頻度で保護されるべきかを、最もよく知っているだろうから、この方法は人的資源をより活用し、データ保護の質の向上をもたらしてくれる。また、これによってバックアップ管理者は、ユーザーのエンドポイントやホームディレクトリーのようなデータセンターの他の部分のデータ保護に集中することができる。
プライマリ・サーバーからプライベートパス経由で、直にバックアップストレージへデータを経由することによって、バックアップサーバーだけでなくバックアップネットワークが不要になる。転送経路がアプリケーションからバックアップアプライアンス直になるからだ。
この方法は、非常に高速のデータ転送を可能にする。この分野のベンダーはExchange、MS-SQL、Oracleのようなアプリケーションが安全にデータ保護されるように、アプリケーション統合のソフトウェアを開発中だ。

即時リカバリー

レプリケーションと復旧用にセカンダリ・ストレージを使えば、非常に厳しい目標復旧時間や目標復旧時点（RPO/RTO）の要求を満たすことができるが、高価な選択肢でもある。これに替わり得る選択肢が、即時リカバリーである。
この機能を提供するデータ保護ソフトウェアは、ブロックレベルの増分バックアップと仮想化技術を使い、データ保護用ストレージ上に直接仮想サーバーを生成する。一般的に、ブロックレベルの増分バックアップのイベントはレプリケーションのイベントほど頻繁に発生しないので、RPO/RTOウィンドウはレプリケーションより若干長くなる。
15分以内に復旧する代わりに、これらの技術は通常1時間未満のRPO/RTO要件を満たしてくれる。こういった環境における大半のアプリケーションにとっては、妥当な値である。復旧時間が長くなるのを受け入れることで、企業はお金を節約できる。データセンターに現在あるデータ保護用ストレージをそのまま使えるので、稼動系のクオリティを持った二次システムを購入する必要がない。
この手法の課題は、データのホストがバックアップアプライアンスになっている間の復旧されたアプリケーションのパフォーマンスである。多くの場合、バックアップアプライアンスは、プライマリ・ストレージと同レベルのパフォーマンスは提供してくれない。とはいえ、大概のアプライアンスは最低限要件を見たすだけのパフォーマンスは提供できるはずだ。ここで重要なのは、バックアップアプライアンスがどの程度のパフォーマンスを提供するかを理解しておくことだ。

アーカイブ統合

（要約）

バックアップ・アプリケーションが進化し、アーカイブ・アプリケーションの機能を持つようになってきた。長期間のデータをサーチする機能などは中小規模の企業向きだ。データの検索はGoogleスタイルで行われる。

最先端のデータ保護ストレージ

ブロックレベルのバックアップ機能と即時リカバリー機能の組合せは、データ保護ハードウェアそのものにも進化をもたらした。これらのシステムはバックアップアプライアンスからデータ保護ストレージへと進化しなければならなくなったのだ。このハードウェアは、様々なソースから同時にデータを取り込み、万一即時リカバリーが使われたときは、場合によっては稼動系アプリケーションをホストするだけのパフォーマンスと信頼性をも提供しなければならないのだ。
今後数年以内にこれらのシステムには、稼動系ストレージに起こったのと同じような、半導体ストレージ統合の波がやってくるだろう。はじめは、半導体ストレージはメタデータを保存するために使われるだろう。その結果、検索と重複排除のインデックスの拡張性が増すと同時に応答性が向上する。しかし最終的には、半導体ストレージの領域は即時リカバリーのターゲットとして使われるようになるだろう。最適なアプリケーションのパフォーマンスを確保するためだ。
いくつかのデータ保護ストレージ製品は、アーカイブ市場へと領域を拡大し、ひとつの製品でのバックアップとアーカイブの一元化を実現している。この動きを加速しているのは、ひとつはアーカイブ機能を持ったアプリケーションだが、もうひとつはディスクをアーカイブ・ターゲット（格納先）として使用するように設計された新しいアーカイブ・アプリケーションの登場によるものだ。これらのストレージ製品は、もっと先の領域へも進出して、データレプリケーションができ、さらにはユーザーのホームディレクトリーのようなNASの基本機能に取って代わる機能まで提供している。これらのストレージ製品は、一般にスケールアウトのアーキテクチャーを採用しているため、高い費用効果で新しいタスクのパフォーマンスおよび容量要求に対応できている。スケールアウト・アーキテクチャーは、ハイパーコンバージドセカンダリーストレージに対するゲートウェイになっており、二次データの保存だけでなく、データ保護アプリケーションおよびレプリケーションアプリケーション自身をホストすることもできる。この機能によって、コストは大幅に削減し、管理は簡素化され、パフォーマンスは向上するだろう。
バックアップはクラウドストレージの使用事例として高い人気を保ってきた。これを具現化した一般的な形は、データをクラウドプロバイダーにレプリケートするオンサイト・バックアップ・アプライアンスである。これらのアプライアンスを代理サーバーとして使って、即時リカバリーがどんなものかを体感することもできる。

オンプレミス・ソフトウェアは、二つの領域で進化を遂げている。一番目は、バックアップパフォーマンスが高速化していることだ。また、インターネット帯域のコストパフォーマンスが、非常によくなってきている。今では、多くの企業が簡単に１ギガバイトのインターネット接続を購入できる。もっと高速な回線でも手の届くところにある。結果的に、アプライアンスを使ってデータをオンサイトに保存する必要性は減ってきている。
全くアプライアンスを使わず、直接クラウドに接続するオプションを提供するベンダーも何社か出てきた。この方が実装もシンプルで、コストも低く保てる。アプライアンスではなく、エクステンダー/キャッシュを使用するベンダーもある。エクステンダーやキャッシュは、データのサブセットだけをオンサイトで保存し、基本的にクラウドのキャッシュとして稼動する。これらの製品は、基幹データのサブセットは常にエクステンダーにもクラウドにも保存し、重要度が低いデータはクラウドだけに保存する機能を提供している。この基幹データのサブセットは、ローカルでの高速リカバリーで使用され、重要度が低いデータはクラウド越しのリカバリーに使われる。データセンターで使用する際、ほとんどの場合、データベースのような大きな基幹系ファイルをエクステンダーに保存し、リカバリーのパフォーマンスにあまり大きな影響を与えない小さなファイルは、クラウドに置くようにするのが良いだろう。

進化した領域の二番目は、DRアズ・ア・サービス（DRaaS）を使ったリカバリーである。これは今となっては最先端ではないが、信頼性は向上しつつある。この機能によって、プロバイダーがクラウド・ベースのデータ保護に対して抱く、クラウドから全データを取り出すのにかかる時間についての大きな懸念が払拭される。それどころか、企業のサーバーがクラウド内で1時間以内に復旧されるのだ。

最先端のバックアップ・アプリケーションは、A地点からB地点へデータをコピーするよりもはるかに多くのことを行う。これらの多くは、最も厳しいRPO/RTO以外の要件を満たすデータ保護アプリケーションスイートのようにも見え、プライマリ・ストレージが自分のデータを保護する機能に対する管理機能を提供している。一見スイートのようにみえるアプローチのメリットは、バックアップ、DR、さらにはアーカイブまでが単一のウィンドウで管理できることである。これによって、管理に要する時間とハードウェア購入コストは低減するはずだ。

著者略歴：George Crumpは、ストレージと仮想化を専門とするITアナリスト企業Storage Switzerlandの社長である