こんにちは。
以前、Engineer VoiceでCohesityのクラウド連携機能を連載形式でご紹介しました。

-------------------------------------------------------------------------------------------
　Cohesity クラウド連携機能のご紹介
　　第1回　CloudArchive編
　　第2回　CloudRetrieve編
　　第3回　CloudTier編
-------------------------------------------------------------------------------------------

Cohesity Softwareバージョン6.4.1より新しいクラウド連携機能として「CloudArchive Direct」が追加されました。 もしかすると「"CloudArchive"との差異が分からない」という方もいらっしゃるかもしれません。 本連載は「第3回」で完結としておりましたが、急遽「第4回 CloudArchive Direct編」にて機能概要ならびに操作イメージをご紹介します。(今回使用しているCohesityバージョンは6.5です。)

　

CloudArchive Directとは

第1回でご紹介した通り、バックアップを一旦Cohesityのローカルに保存し、これを外部ターゲットに送るのがCloudArchiveです。
一方でCloudArchive Directはバックアップをローカルに保存せず外部ターゲットに送ります。ただし、当該のバックアップに関するIndexやメタデータはCohesityのローカルに保存されますので、Cohesity Dashboardからバックアップデータの検索を行えるようになっています。
なお、Cohesityバージョン6.5時点ではCloudArchive Directを行えるのはNASバックアップのみです。

では、実際にジョブを作成しバックアップ・リカバリを行ってみましょう。

　

CloudArchive Directの設定・実行

前述の通りCloudArchive Directを行えるのはNASバックアップのみです。 従って今回はNetAppのNFSボリュームを対象にバックアップ・リストアを行います。NetAppのNFSボリュームにランダムテキストデータを書き込んでおきました。
なお、NASバックアップに関しては先日公開したブログで詳細をご紹介していますので、こちらを先にご覧頂くことをお薦めします。

(1) 外部ターゲットの登録

外部ターゲットの登録はCloudArchiveのときと同じです。 今回もAzure Hot Blobを利用します。

(2) ポリシーの作成

CloudArchive Directを利用するためのポリシーを作成します。 CloudArchive Directを利用するにあたっては、以下の要件を満たすポリシーが必要です。以下を満たすポリシーが存在しない場合、Protection Group(バックアップジョブ)作成時にポリシーを指定することができません。
　・再試行回数が0になっていること
　・レプリケーションの設定が存在しないこと
　・アーカイブ設定が含まれていること
今回は以下のようにポリシーを作成しました。

(3) ソースの登録

バックアップ対象のNASをソース(Source)として登録します。 ここではNetApp Clusterをソースとして登録しています。 詳細はこちらの記事をご参照ください。

(4) Protection Groupの作成、実行

ここからNASのProtection Groupを作成していきます。ここでCloudArchive Direct設定を有効化する必要があります。
またCloudArchive Direct設定を有効化すると、バックアップ対象として選択できるオブジェクト(NAS領域)は1つのみになる点にご留意ください。CloudArchive Directを行いたいオブジェクトが複数ある場合は、ひとつひとつに対してProtection Groupを作成する必要があります。(オブジェクトの選択方法がチェックボックスではなくラジオボタンになっていますので、複数選択はできないようになっています。)

オブジェクトを選択した後は、グループ名(Protection Groupの名称)を入力してポリシーを指定します。 「(2)ポリシーの作成」でCloudArchive Direct用のポリシーには条件があることをお伝えしましたが、ここでは条件を満たすポリシーしか選択できないようになっています。(条件を満たさないポリシーはドロップダウンリストに表示されません。)

設定が終わりましたら[バックアップ]ボタンをクリックします。

(5) ジョブ実行結果の確認

バックアップとアーカイブにそれぞれ緑のチェックがついていれば完了です。
　

リカバリの実行

バックアップデータ自体はクラウド側にあるものの、バックアップデータを検索するIndexはCohesityのローカルにありますので、バックアップデータの検索やリカバリ操作は通常のNASバックアップのときと変わりありません。

ここでは元の場所にリカバリしてみたいと思います。(NASバックアップからのリカバリについては以前の記事でご紹介していますので、詳細についてはこちらをご参照頂ければと思います。)

Dashboardで[回復]をクリックして「ストレージボリューム」を選択します。

Protection Group名の一部でバックアップデータを検索します。
ボリューム名をクリックするとリカバリタスク作成画面に移ります。「元の位置」を選択して[回復を開始]をクリックします。

ステータスが「成功」になれば完了です。
　

CloudRetrieveによるリカバリも可能

本記事の冒頭でCloudArchive Directの動作について触れましたが、掲載した図の中で外部ターゲット側にもIndexとメタデータが存在することにお気づきになられましたでしょうか。
CloudArchive DirectもCloudArchiveと同様に、Cohesityローカルと外部ターゲットの両方にIndexとメタデータが保管されます。このため災害等によりCloudArchive Directを実行したCohesity Clusterが全損しても、外部ターゲット側にデータが残っていれば別のCohesity ClusterからCloudRetrieveによりリカバリを行うことができます。

ここからは、CloudArchive Directで取得したバックアップデータを利用してCloudRetrieveを行う様子を簡単にご紹介します。 (CloudRetrieveの仕組みや操作画面の詳細な説明についてはこちらの記事をご参照ください。)
CloudArchive Directを実行したCohesity Clusterとは別のClusterを用意し、CloudRetrieveを行ってみます。

まずはDashboardのCloudRetrieve画面で[検索を開始]ボタンをクリックします。

まだこちらのCohesity Clusterには外部ターゲットが登録されていませんので、「外部ターゲットを登録」をクリックしバックアップが保管されているAzure Blobを登録します。
CloudArchive Directを実行したCohesity Clusterやジョブ名(Protection Groupの名前)などを入力して[検索]をクリックします。

検索結果が表示されたらStorage Domainを指定して[ダウンロード]をクリックします。
ダウンロードが完了しました。

これでCloudArchive DirectされたバックアップデータをこのCohesity Clusterで扱えるようになりました。
例えばDashboardでProtection Group名で検索をかければ、以下のように取得したバックアップの情報が見えてきます。(こちらはファイル・フォルダーレベルでリカバリを行う画面の一部です。) あとは通常と同様にリカバリを行うことができます。
　

今回はCloudArchive Directをご紹介しました。
CloudArchive DirectはCohesityのローカルにはバックアップデータを残しませんが、Indexやメタデータはローカルに保管されていますので、通常のNASバックアップと同様の操作感でリカバリできることがお分かり頂けたのではないかと思います。
本記事がCloudArchiveとCloudArchive Directとの違いを整理する上での一助となりましたら幸いです。

　

※ 今回使用した環境はCohesity Softwareバージョン6.5.0です。サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。

Cohesity社ウェブサイト: https://www.cohesity.com/ja/