エージェントレスな手法を使用して効率的なバックアップとリカバリーを行う

IBM SmarterCloud Enterprise で Asigra クラウド・バックアップを使用する

クラウドに関する現在の状況は数年前とは少し異なるようです。大きな違いの 1 つは、今やクラウドには一般コンシューマー向けの Web アプリケーションが置かれるのみならず、企業向けの製品レベルのアプリケーションもクラウドでホストされるようになっている点です。また、仮想化されたクラウド・データ・センターは、高速かつ効率的な方法でのデータ・アクセスおよびデータの格納、さらには潜在する問題が発生した場合のエンタープライズ・アプリケーション・データのデータ・リカバリーなどを行う上で効果的なバックアップを実践しているため、こうしたデータの扱いをするための優れた選択肢となります。この記事では、従来のエージェント・ベースのバックアップ手法よりも優れたクラウド指向のデータ・リカバリー手段を提供するエージェントレスなバックアップ手法を提案します。まず始めにバックアップ手法の選択肢を紹介し、続いて著者らが開発した、IBM SmarterCloud Enterprise 上で実行される実際のエージェントレス・クラウド・リカバリー・システムについて説明します。

Douglas Ko, Director of Strategic Alliances, Asigra

Doug Ko は戦略的提携担当ディレクターとして、IBM など、Asigra のベンダー・パートナーと共に顧客ニーズや新たな市場機会に対応する共同ソリューションの開発、市場導入を行っています。彼は以前 Varicent Software に在籍し、Microsoft、Salesforce.com、Research in Motion などの業界リーダーと世界的な ISV アライアンスを行っていました。その前は Bycast で、アライアンス部門、販売部門、セールス・エンジニアリング部門、マーケティング部門に在籍していました。Bycast の前は半導体業界の市場リーダー PMC-Sierra と ATI Technologies に在籍し、それぞれマーケティングと技術職を担当しました。彼はトロント大学 (University of Toronto) で電気工学の (優等) 学位を取得しています。



Sergey Perchak, Systems Engineer, Asigra

Sergey Perchak はクラウド・バックアップとリカバリー・ソリューションの世界的リーダー、Asigra のシステム・エンジニアです。彼はストレージ、ネットワーキング、データ管理、データ保護などの多様な IT 分野に 15 年を超える経験があります。



2012年 11月 08日

クラウドの採用が加速され、企業向けの製品レベルのアプリケーションがクラウドでホストされるようになるのに伴い、管理者は、従来のエージェント・ベースのバックアップ・ソリューションがクラウド環境には不向きであるという難題に直面しています。エージェントレスなバックアップおよびリカバリー技術は、従来の手法よりも優れており、データ・リカバリーを単純化、そして迅速化することができます。

この記事では、エージェントレスなバックアップおよびリカバリー手法についての概要と、この手法がクラウドでどのように動作するのかを説明します。

なぜエージェントレスなバックアップおよびリカバリー手法が重要なのか

IT の世界は変化しています。クラウド・コンピューティングのバックアップとリカバリーも、この変化と無縁ではありません。アプリケーションとデータが一体でホストされたデータ・センターで使用されていた従来のバックアップ手法、またクラウド初期の成長を促す源となった一般コンシューマー向けの Web アプリケーションを主な対象として設計されたデータ保護スキームは、クラウド内で実行される企業向けの製品レベルのアプリケーションを対象として最適に設計されているわけではありません。

一般的に、エージェントレスなバックアップおよびリカバリー技術はクラウド環境用にゼロから設計されており、手作業やリソースをあまり必要とせずに柔軟なデータ・リカバリーを実現する、管理の容易なソリューションを提供することができます。これはクラウド・ユーザーにとって、手間や関連コストが減り (その大部分は自動化の結果です)、リカバリーが迅速に行われるということです。

では、現在のクラウドのバックアップに至るまでのバックアップの進化について見てみましょう。


バックアップが進化して現在のクラウドのバックアップへ至る道のり

ここでは、下記 2 種類の従来のタイプの Web ベースのバックアップ方式について詳しく見ていきます。

  • エージェント・ベースのバックアップ
  • 仮想イメージのバックアップ

従来のエージェント・ベースのバックアップ

これまでも、オペレーティング・システム、ファイルシステム、アプリケーションなどのデータのスキャンや収集のために、エージェントが使用されてきました。エージェントにより、データ・セット全体やインクリメンタルなファイル変更、インクリメンタルなブロック変更をバックアップすることができます。

最近ではエージェントの機能が強化され、重複排除、圧縮、暗号化もエージェントが行えるようになりました。これらの機能はどれも、一定量のシステム・リソースを必要とします。図 1 に典型的なエージェント・ベースのバックアップ・システムを示します。

図 1. エージェント・ベースのバックアップ・ソフトウェアの典型的なデプロイメント例
エージェント・ベースのバックアップ・ソフトウェアの典型的なデプロイメント例

構造化データベース (RDBMS、e-メール、ERP など) をバックアップするためのアプリケーション・エージェントは、通常はシステム・エージェントに追加される固有のエージェント、つまり固有のコードです。各エージェントはそのシステムに固有であり、他のシステムやアプリケーションと共有することはできません。

エージェントはすべての機器にインストールされている必要があります。従来のバックアップ・ソフトウェアやデータ保護ソフトウェアの大部分は自動的にエージェントを追加するわけではないため、管理者が各機器に手作業でエージェントをインストールする必要があります。これはパッチや修正、アップグレードの場合も同じです。

バックアップ・エージェントの多くは、すべてを中断することになるアプリケーション・システムのリブートも必要とします。そのため、すべての実装、アップグレード、パッチ、修正をスケジューリングして一斉に実行しなければなりません。大量のエージェントがある場合、このプロセスは少し厄介であり、バックアップ管理者は予定されているメンテナンスのタイミングまで更新やパッチを延期しがちです。

サーバーの仮想化が最初に一般的になった頃、仮想マシン (VM) のバックアップは物理マシンのバックアップと同じように行われていました。この方式では各エージェントがリソースを使用するため、VM の集中化や統合は進みませんでした。VM が多いということは、エージェントが使用するリソースも多くなるということです。

バックアップは I/O の競合も引き起こしました。これは各エージェントが並行してバックアップを実行しようとするためですが、それは多くの場合、同じリソースに対して競合していることをエージェントが認識していなかったことが原因です。その結果バックアップのパフォーマンスが低下し、バックアップのタイミングを失うことがよくありました。

仮想イメージ・バックアップの登場

ハイパーバイザーのベンダー達はエージェントのオーバーヘッドが受け入れがたいことに気付き、仮想マシンをバックアップするための別の手法を開発しました。今日の大部分のハイパーバイザーは、ハイパーバイザー・ネイティブのスナップショットを利用してバックアップを行える何らかの API を備えているため、ハイパーバイザーはエージェントを使用することなくバックアップ・プロセスの負荷を減らすことができます。

ハイパーバイザーの API を使用することで、バックアップ・ソフトウェアのメディア・サーバーは、特定の VM または一連の VM (もっと具体的に言えば VM に関連付けられた仮想ディスク) のスナップショットの作成を始めることができます。仮想化のスナップショットを作成することで、VM を完全にロールバックしてリカバリーすることが可能になります (このリカバリーは多くの場合、誤ってベアメタル・リストア (BMR: Bare Metal Restore) と呼ばれています)。BMR は対象となるデータ量が多いことから、かなり長い時間を要するプロセスです。ユーザーへの調査では、これまでに行ったリカバリーとリストアのなかで、マシン全体を対象にしたリカバリーやリストアではなく、1 つのファイルを対象にしたリカバリーやリストアの割合が 90 パーセントを超えているという結果が常に得られています。しかし VM のロールバックが必要な場合には、BMR はそのための迅速かつ容易な手段となります。

仮想化イメージのバックアップ内でのファイル・レベルのリカバリーに対処するオンプレミス・バックアップ製品がいくつかありますが、それらの多くは特定の仮想化プラットフォームやハイパーバイザー専用です。ハイパーバイザーのスナップショット、つまりイメージを取り込むためにクラウド・サーバーをオフラインにする (計画的なダウンタイムの) 必要があるような状況や、データ・リカバリーのために VM リソースの追加が必要な状況、あるいは複数時点でのスナップショットやクローン・イメージのスナップショットを取り込むために、ストレージ容量の大幅増加が必要となるような状況があります。図 2 に、仮想イメージのバックアップとスナップショットのセットアップを示します。

図 2. 仮想イメージのバックアップとスナップショット
仮想イメージのバックアップとスナップショット

では、エージェントレスなバックアップとリカバリーについての説明に移りましょう。


より賢明なクラウド・バックアップ: エージェントレス

エージェントレスなバックアップの設計を使用する場合には、すべてのサーバー、アプリケーション、機器にエージェント・ソフトウェアをインストールする代わりに、1 つまたは複数の物理データ・コレクターや仮想データ・コレクターにデータ・アクセスを統合します。各データ・コレクターはソースとなるサーバー、アプリケーション、機器からバックアップ用のデータをプルします。データ・コレクターには各バックアップ・ターゲットから適切なクレデンシャルが与えられ、またデータ・コレクターはネイティブ API を使用してデータをプルします。高速なバックアップを確実にするために、データ収集は LAN の速度で実行されます。それを示したものが図 3 です。

図 3. エージェントレスなバックアップ・ソフトウェアのデプロイメント例
エージェントレスなバックアップ・ソフトウェアのデプロイメント例

以下に記載するいくつかのタイプのエージェントレスなバックアップについて調べてみましょう。

  • ファイル・ベースのバックアップ
  • VM のスナップショットのバックアップ
  • アプリケーションに対応したバックアップ

ファイル・ベースのエージェントレスなバックアップ

ファイル・ベースのエージェントレスなバックアップは、OS ベースの API を使用してファイルにアクセスすることで実現されます。

  • Windows サーバーの場合には、適切なクレデンシャルがデータ・コレクターに与えられ、データ・コレクターは Windows のファイル・サービス API を使用してファイル・ベースのバックアップを実行します。
  • Linux ベース、Unix ベースのサーバーの場合には、適切なクレデンシャルがデータ・コレクターに与えられ、データ・コレクターは SSH または NFS プロトコルを使用してファイル・ベースのバックアップを実行します。

それを説明したものが図 4 です。

図 4. ファイル・ベースのエージェントレスなバックアップでのデータ・アクセス
ファイル・ベースのエージェントレスなバックアップでのデータ・アクセス

VM のスナップショットのエージェントレスなバックアップ

仮想クラウド・サーバーのエージェントレスなバックアップを実現するには、仮想化ハイパーバイザーの API を使用するか、ファイルのエージェントレスなバックアップを通じて行います。VM のスナップショットをバックアップするには、ハイパーバイザーの API を呼び出し、1 つまたは複数の VM のスナップショットを取るようにハイパーバイザーに指示し、スナップショットのイメージをコピーします (VMware の場合、最初のスナップショットの後は CBT (Change Blocks) のみをコピーします)。

この操作により、VM のイメージを完全にバックアップすることができます。各 VM イメージは要求に応じてロールバックすることができます。失敗した場合には、そのイメージを別のクラウド・サーバーに直接マウントして実行することができます。

ハイパーバイザーの API またはファイルのエージェントレスなバックアップを使用すると、ハイパーバイザーやオペレーティング・システムの種類によらず迅速かつ柔軟にデータをリカバリーすることができます。それを説明したものが図 5 です。

図 5. イメージまたはスナップショットのエージェントレスなバックアップでのデータ・アクセス
イメージまたはスナップショットのエージェントレスなバックアップでのデータ・アクセス

アプリケーションに応じたバックアップ

エージェントレス技術では、構造化データベース・アプリケーションのバックアップに使用するバックアップ・エージェントを最小限にするために、エージェントレス技術とアプリケーション専用の API とを直接統合します。通常は、そのアプリケーションを実行するバックアップ対象のシステムに対し、そのアプリケーション専用の API を使用するシン・クライアントがインストールされます。このシン・クライアントにより、データ・コレクターはデータベース API に対し、データベースの休止 (つまり一時停止)、キャッシュのフラッシュ、書き込みの完了、データベース・データのフラット・ファイルへのダンプ、そしてデータベースの再開を指示することができます。これはホット・バックアップと呼ばれ、データベースをオフラインにする必要がありません。

API の機能によっては、データベース内の特定のテーブルまたは項目のみを対象にバックアップとリカバリーを行える場合があります。そうしたデータベース API の例としては、Oracle の RMAN/SBT、DB2 のバックアップおよびリストア API、SQL Server の SQLVDI などがあります。

Windows サーバーには、VSS (Volume Shadow Copy Services: ボリューム・シャドウ・コピー・サービス) と呼ばれる組み込みの API によってスナップショットをとるメカニズムがあるため、シン・クライアントは必要ありません。これは Microsoft アプリケーションや、VSS を利用できるように変更された他のデータベース構造化アプリケーションには非常に有効です。それを説明したものが図 6 です。

図 6. アプリケーションに応じたバックアップでのデータ・アクセス
アプリケーションに応じたバックアップでのデータ・アクセス

では実際の例として、私達が設計したエージェントレスなバックアップおよびリカバリー・システム、Asigra Cloud Backup を見てみましょう。


IBM SmarterCloud での Asigra Cloud Backup

Asigra におけるエージェントレスなバックアップの起源は 25 年以上も前の 1986年に遡ります。Asigra の創設者である David Farajun は、失われたデータのリカバリーでビジネスを支援するためにはどうすればよいか、という問題の解決に乗り出しました。Farajun は以下の 5 つの設計原則に従った開発を開始しました。

  • 人間の介在を可能な限り少なくする
  • バックアップした情報をオフサイトの場所に格納する
  • すべてのビジネス情報を集中バックアップする
  • コンピューティング環境を保護する
  • 迅速かつ高い信頼性のリカバリー

人間の介在を最小限にすると同時にすべてのビジネス情報を集中化するために、Farajun はダイアルアップ・モデムを介してバックアップおよびリカバリーのサービスを提供できるプラットフォームの作成にフォーカスしました。その結果、業界初のエージェントレスなバックアップおよびリカバリーのプラットフォームが開発されました。

Asigra Cloud Backup ソフトウェアは、データ・パス上にある 2 つのコア・コンポーネント、DS-Client と DS-System で構成されています。

  • DS-Client は、物理サーバー・アプライアンスまたは仮想サーバー・アプライアンス上で実行される Windows、Linux、Mac OS X オペレーティング・システムにインストールされるエージェントレスなデータ・コレクターです。各 DS-Client は何十台から何百台という物理サーバーや、仮想サーバー、あるいはデスクトップ・マシンをバックアップし、また DS-Client をグリッド構成に追加、接続することで、スケーラビリティーや、フェイルオーバー、ロード・バランシングなどを実現することができます。DS-Client は SmarterCloud Enterprise 上で実行されるクラウド・サーバーをバックアップすることや、顧客の施設に DS-Client を配置することで、ローカルの物理サーバーや仮想サーバーのバックアップ、さらには構造化データベース・アプリケーションおよびデスクトップ・マシンのバックアップをすることができます。

    各 DS-Client は、バックアップ要件や、バックアップに要する時間、WAN 帯域幅が最小限で済むように設計されています。DS-Client は変更されたブロックの差分の追跡から開始し、最初のバックアップ後は新しいデータと変更されたデータのみを取り込みます。そしてデータがバックアップ保管庫、つまり DS-System (ほとんどのバックアップ・ベンダーがメディア・サーバーと呼ぶもの) に送信される前に、データは重複排除、圧縮、そして NIST FIPS 140- 2 に準拠して認定を取得済みの 256 ビットデータ暗号化による暗号化などが行われます。これらの構成は各 DS-Client で個別に行うことができます。

  • DS-System はマルチテナント型のデータ保管庫であり、多数の DS-Client から送信されたすべてのバックアップ・データを集約して格納します。DS-System は Windows または Linux オペレーティング・システム上にインストールすることができ、DS-Client と同じデータ・センターにも別のデータ・センターにも配置することができます。さらに冗長性を高めるために、複製された DS-System を災害復旧用にリモートのデータ・センターにインストールすることもできます。1 つの DS-System で何十から何百もの DS-Client のバックアップ・データを集約することができたり、DS-System を追加、接続して N+1 構成にすることで、スケーラビリティーや、フェイルオーバー、ロード・バランシングなどを実現することができたりします。

    信頼性の高いデータ・リカバリー手段がない限り、データ・バックアップ単体では使い物になりません。DS-System はデータ完全性を改善するために、自律的な回復プロセスを実行します。このプロセスはデータの完全性をチェックして、さまざまなデータ破損の問題を自動修正する自動ヘルス・チェックのプロセスです。また DS-System はバックグラウンドでデータを自動的にリストアし、バックアップされたデータが常にリカバリー可能であることを確実にすることで、リストアの検証も行います。

では、SmarterCloud Enterprise 上での Asigra Cloud Backup のイメージのワークロード・トポロジーについて、その一部を見ていきましょう。その後で、SmarterCloud 上で Asigra Cloud Backup を使用する方法について説明します。

Asigra Cloud Backup のイメージ

Asigra Cloud Backup ソフトウェアは、パブリック・イメージ・カタログの一部として IBM SmarterCloud Enterprise にプリロードされています。Asigra の DS-Client、DS-System、その他の Asigra ツールや管理ソフトウェアはパブリック・イメージに含まれています。このソフトウェア・イメージをさまざまなトポロジーに配置し、多種多様なバックアップ用途をサポートすることができます。

SmarterCloud クラウド・サーバーのバックアップ
図 7 に示す例では、1 つの DS-Client が Windows バックアップ用にデプロイされ、別の DS-Client が Linux バックアップ用にデプロイされています。必須ではありませんが、両方の DS-Client、そして Windows サーバーと Linux サーバーも、同じ VLAN 上にあります。

図 7. SmarterCloud クラウド・サーバーのバックアップを同じデータ・センター内にデプロイする
SmarterCloud クラウド・サーバーのバックアップを同じデータ・センター内にデプロイする

DS-Client はバックアップ・データを (1 つまたは複数の) DS-System に送信する前に、データの暗号化、圧縮、重複排除を実行します。DS-System は、デフォルトでは同じ SmarterCloud データ・センターの同じ VLAN 上にありますが、地理的に分離するためや、バックアップ・データの二次コピーとして、オプションで別の SmarterCloud データ・センターに配置することもできます (図 8)。

図 8. SmarterCloud サーバーのバックアップを別のデータ・センターにデプロイする
SmarterCloud サーバーのバックアップを別のデータ・センターにデプロイする

SmarterCloud の外部にあるサーバーや機器を SmarterCloud 内でバックアップする
この例と、先ほどの例との主な違いは、SmarterCloud の外部にあるリモートの物理サーバーや仮想サーバー、構造化データ・アプリケーション、デスクトップ・マシンなどを、DS-Client を使用してバックアップする点です。各 DS-Client の間がネットワークで接続されている限り、各 DS-System は各 DS-Client の物理的な場所にかかわらず複数の DS-Client をサポートすることができます。

図 9 の DS-Client はバックアップ対象マシンのローカル・ネットワーク上にあります。ノート PC、スマートフォン、タブレットなどのモバイル機器の場合には、必要最低限の機能を実装したモバイル向け DS-Client がアプリケーションとして機器上に常駐します。

図 9. SmarterCloud の外部にあるサーバーや機器のバックアップを SmarterCloud にデプロイする
SmarterCloud の外部にあるサーバーや機器のバックアップを SmarterCloud にデプロイする

SmarterCloud 上で使用する

このセクションでは、Asigra Cloud Backup を使用して SmarterCloud サーバー・インスタンスのバックアップを始めるために必要な主要ステップの概要を説明します。ステップバイステップの詳細な説明については、各種 Asigra ユーザー・ガイドの参照箇所を記載してあります。

SmarterCloud サーバー・インスタンスのバックアップは、基本的には以下のように行います。

  1. Asigra インスタンスを作成する
  2. ライセンスを処理する
  3. DS-Client アカウントを登録する
  4. バックアップ・セットを作成する
  5. バックアップを実行する
  6. データをリストアする

ステップ 1. パブリック・イメージ・カタログから新しい Asigra インスタンスを作成する
図 10 に SmarterCloud のパブリック・イメージ・カタログ内にある Asigra インスタンスを示します。

図 10. SmarterCloud のパブリック・イメージ・カタログ内にある Asigra インスタンス
SmarterCloud のパブリック・イメージ・カタログ内にある Asigra インスタンス

2 つの Red Hat Linux イメージと 1 つの Windows イメージがあります。

  • Asigra Cloud Backup v11.2 64b (BYOL): このイメージはベースとしての Linux を構成するためのものであり、DS-Client または DS-System として、あるいは他の Asigra ソフトウェア・コンポーネントとして Linux を構成することができます。インストールおよび構成の命令は、イメージ内の <PATH> で実行されます。
  • Asigra Cloud Backup v11.2 demo 64b (BYOL): このイメージは小規模なデータ負荷やデモ環境をバックアップするためのものです。このイメージには、Asigra の主なソフトウェア・コンポーネントがすべてプリインストールされて構成されています。
  • Asigra Cloud Backup v11.2 Windows 64b (BYOL): このイメージはベースとしての Windows を構成するためのものであり、DS-Client または DS-System として、あるいは他の Asigra ソフトウェア・コンポーネントとして Windows を構成することができます。インストールおよび構成の命令は、イメージ内の <PATH> で実行されます。

ここでは DS-System と DS-Client の両方がプリインストールされていることから、2 番目のイメージを使用します。

ステップ 2. ライセンス・サーバーに接続する
Asigra Cloud Backup ソフトウェアは SmarterCloud 上で BYOL (Bring Your Own License) としてライセンスされています。ユーザーは Asigra から、または Asigra のサービス・プロバイダーまたは再販売業者からライセンスを入手する必要があり、ライセンスを入手することによって DS-System をライセンス・サーバーに接続できるようになります。

ライセンス・サーバーに接続するには、DS-System サーバーにリモート・ログインし、DS-Operator GUI インターフェースを起動する必要があります。DS-Operator で「Setup menu (セットアップ・メニュー)」 > 「License Server (ライセンス・サーバー)」の順に選択し、プライマリー・ライセンス・サーバーの IP アドレスまたは DNS (そして、オプションとして図 11 のようにイマージェンシー・ライセンス・サーバーの IP アドレスまたは DNS) を入力します。

図 11. DS-Operator GUI のライセンス・サーバー・ダイアログ・ボックスに入力する
DS-Operator GUI のライセンス・サーバー・ダイアログ・ボックスに入力する

ステップ 3. DS-Client のアカウントを作成し、登録する
DS-Client を DS-System に接続するには、DS-Operator GUI インターフェースを使用して DS-Client のアカウントを作成し、DS-System に登録する必要があります。(この点については、イメージに含まれている DS-Operator Manual の Section 4 に DS-Client に関する詳細が説明されています。)

参照しているデモ・イメージの場合には、既に 1 つの DS-Client アカウントが DS-System に登録されています。

ステップ4. バックアップ・セットを作成する
エージェントレスなバックアップは DS-Client から開始されます。DS-Client の構成と管理には DS-User GUI を使用します。DS-Client サーバーにログインし、DS-User GUI を起動します。さまざまなアプリケーションが Windows 版と Linux 版の DS-Client でサポートされています。

「New Backup Set Wizard (新規バックアップ・セット・ウィザード)」によって、ステップバイステップの手順でバックアップ・セットを作成して構成することができます (図 12)。

図 12. DS-User GUI に表示された Windows 版と Linux 版の「New Backup Set Wizard (新規バックアップ・セット・ウィザード)」
DS-User GUI に表示された Windows 版と Linux 版の「New Backup Set Wizard (新規バックアップ・セット・ウィザード)」

このウィザードではオプションとして、バックアップ・セットのタイプの選択、サーバーおよびアプリケーションのクレデンシャルの入力、バックアップ対象の項目の指定、オプションの指定、保持ルールの構成をすることができます。詳細については、イメージに含まれている DS-Client User Guide の Section 4 の「Creating and Modifying Backup Sets (バックアップ・セットの作成と変更)」を参照してください。

ステップ 5. バックアップを実行する
バックアップは、スケジューリングすることで事前に設定した時刻に実行することも、DS-User GUI からオンデマンドで実行することもできます。バックアップのスケジューリングとオンデマンド・バックアップについては、on-cloud DS-User Guide の Section 3 と Section 8 にそれぞれ詳しく説明されています。スケジューリング用のウィンドウは図 13 のようなものです。図 14 はオンデマンド・バックアップ・ウィザードです。

図 13. DS-User GUI として表示される、バックアップの「Schedule (スケジュール)」ウィンドウ
DS-User GUI として表示される、バックアップの「Schedule (スケジュール)」ウィンドウ
図 14. オンデマンド・バックアップのための「Backup Now Wizard (今すぐバックアップ・ウィザード)」
オンデマンド・バックアップのための「Backup Now Wizard (今すぐバックアップ・ウィザード)」

ステップ 6. データをリストアする
DS-User GUI にはデータをリストアするためのリストア・ウィザードが用意されています。バックアップ・セットやオリジナルのソース・データのタイプによって、さまざまなオプションがあり、どのようなデータを (個々のファイル、ディレクトリー、データベース、テーブルなど)、どこに (元の場所または別の場所)、どのように (パフォーマンス・オプションとリストアオプション) リストアするかを選択することができます。詳細については、on-cloud DS-Client User Guide の Section 9 の「Restoring Backups (バックアップのリストア)」を参照してください。それを示したのが図 15 です。

図 15. DS-User GUI として表示される「Restore Now Wizard (今すぐリストア・ウィザード)
DS-User GUI として表示される「Restore Now Wizard (今すぐリストア・ウィザード)

ここで説明した例は、SmarterCloud 上で Asigra Cloud Backup を使用してバックアップとリカバリーを行う場合の単純な例にすぎません。この記事では詳細に説明しませんでしたが、このソフトウェアにはバックアップとリストアのための包括的な機能セットが用意されています。


まとめ

バックアップは管理者にとって決して楽しい作業ではなく、またクラウド・コンピューティングによって新しい機会が生まれると共に、バックアップの新たな課題も生まれます。データの保護やバックアップにはさまざまな方法がありますが、従来の手法の大部分はあまりクラウドには適していません。IBM SmarterCloud Enterprise で Asigra Cloud Backup を使用すると、その自動化されたエージェントレスなバックアップ手法によって、クラウド・サーバーのバックアップに関する課題と要件に最適な形で対応できるため、大きなメリットがもたらされます。Asigra Cloud Backup により、ユーザーは SmarterCloud 上で実行されるサーバーやアプリケーションを多様なオプションを活用してバックアップおよびリカバリーすることができます。また、SmarterCloud の外部にあるバックアップ・サーバーやバックアップ機器を SmarterCloud 内に含めるようにデプロイメントを拡張することもできます。

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmarterCloud Enterprise で利用可能な製品イメージを調べてみてください。
  • Asigra はクラウドのバックアップ、リカバリー、リストアのための製品を提供しています。Asigra Cloud Backup について調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Information Management
ArticleID=844138
ArticleTitle=エージェントレスな手法を使用して効率的なバックアップとリカバリーを行う
publish-date=11082012