グローバルな標準がない

　ストレージシステム、OS、ハイパーバイザーには通常何らかの形でスナップショット機能が組み込まれている。だがその機能は、該当の製品を使用する環境に固有のものだ。つまりベンダーA社のスナップショットは、一般にベンダーB社の製品では機能しない。結果としてデータセンターでは、スナップショットツールを複数管理しなければならなくなる。ストレージシステムごとに、少なくとも1つ以上のツールを管理する必要がある。スナップショットの共通標準がないため、OS、ハイパーバイザー、ストレージシステムなどの各プラットフォームで、スナップショットスケジュールを個別に管理・監視しなければならない。

インデックスがない

　スナップショットにインデックスが付けられないことも一般的には問題だ。つまりファイルの各バージョンを見つけるために、バックアップ用スナップショットを検索する簡単な方法がない。そのためIT担当者は、各スナップショットを調べてそこに含まれるデータを探さなければならない。大抵の場合、探しているファイルが含まれていそうな各スナップショットイメージを個別にマウントあるいは検索することになる。

詳細情報が添えられていない

　既存のストレージプラットフォームには、パフォーマンスに影響を与えることなく何千ものスナップショットを取得できるものもある。だがインデックスがない何千ものスナップショットを取得する価値があるとは思えない。スナップショットだけを利用してデータを保持している場合、ファイルの特定のバージョンを素早く簡単に見つけられないのは問題だ。加えて時間が経つにつれ、特定のスナップショットの内容を覚えておくのも難しくなる。

信頼性が低い

　スナップショットは唯一のデータ保護技術として利用するには信頼性が低い。スナップショットの基盤となるストレージシステムやボリュームで障害が起きると、そのシステムやボリュームにひも付く全てのバックアップ用スナップショットが使えなくなる。この問題を回避する方法の一つは、スナップショットデータを別のシステムに複製することだ。ほとんどの場合、複製先である2つ目のシステムは1つ目のシステムと同じである必要がある。システムのベンダーも同じでなければならない。ほぼ同じシステムをもう一つ購入すれば、コストが2倍になるのは明らかだ。さらに2つ目のシステムは、災害復旧場所に用意することが多いため、利用するにはWANを通じてデータを取得しなければならない。

粒度が粗い

　ほとんどのスナップショットはボリュームレベルで運用される。特定のボリュームのスナップショットを詳しく調べるには、そのボリュームをマウントしなければならない。ファイルを検索して見つけるのも難しい。DRに利用するのがボリュームの一部のみであっても、ボリューム全体を複製しなければならない。

　こうした問題点があるにもかかわらず、スナップショットは無視できない強力な機能だ。管理者はスナップショットの役割を制限し、最新バージョンのデータのみを復元する。これは発生頻度が最も高い種類の復元だ。IT部門は、スナップショットを従来のバックアップやアーカイブと組み合わせて、完全かつ完璧に機能するデータ保護を提供する必要がある。

バックアップを補完するスナップショット

　スナップショットをバックアップと連携させると、高品質で忠実度の高いデータ保護を実現できる。最悪の場合でも、IT部門はスナップショットとバックアップについて、2つのデータ保護ツールを相互に独立した状態で運用可能だ。バックアップを実施する直前の時点にスナップショットを取るよう設定し、バックアップとボリュームのスナップショットのバージョンを合わせるとよい。その結果、アクティブではないファイルシステムもバックアップでき、理想的なバックアップになる。バックアップ完了時には、スナップショットを忘れずに削除する。

　ここに統合のチャンスがある。統合の第1段階は、バックアップソフトウェアを通じて一連の操作スクリプトを実行することだ。具体例としては、バックアップソフトウェアからストレージシステムを呼び出し、バックアップが必要なボリュームのスナップショットを作成する。次にそのボリュームのスナップショットバージョンを、指定した場所にマウントする。そしてマウントしたスナップショットバージョンをバックアップし、完了したら該当するボリュームのスナップショットバージョンを削除する。

　このスクリプトによるアプローチの課題は、スナップショット機能に対してストレージシステムごとにインタフェースが固有であることだ。つまりIT部門は、データセンター内のストレージシステムのブランドごとにスクリプトを作成することになる。バックアップソフトウェアやストレージシステムの更新に合わせ、これらの各スクリプトを管理・更新する必要もある。

　統合の第2段階は、バックアップソフトウェアベンダーが自社のソフトウェアを、主要なストレージベンダーのシステムと直接連携させることだ。このシステムとはストレージシステムやバックアップスナップショットを指す。つまりバックアップソフトウェアベンダーは、スナップショットでバックアップを置き換えるのではなく、スナップショットとバックアップを一元管理する。この統合によって、スナップショットをストレージシステムごとに管理する必要がなくなり、バックアップ管理者は各ストレージシステムに精通していなくても全てのジョブを設定できる。ただし注意点が1つある。バックアップソフトウェアとストレージシステムがバージョンアップしても、スナップショットとの連携が正しく動作するかどうかは、バックアップソフトウェアベンダーの対応次第だ。

　統合の第3段階は、バックアップソフトウェアがストレージシステムのスナップショットを復元に利用できるようにすることだ。これはバックアップソフトウェアが、特定のファイルまたは一連のファイルからバックアップ要求を受け取るときに利点をもたらす。すなわち、バックアップスナップショットにそのファイルデータが含まれるかどうかを特定できる。そうすればバックアップストレージの代わりに、スナップショットからデータを復元可能となる。ストレージシステムのスナップショットとバックアップの完全な統合における価値は、バックアップソフトウェアが全てのデータ保護操作の「司令塔」になれることだ。管理者はデータセンターの全てのストレージシステムについて、単一のインタフェースで管理できるようになり、保護プロセスを完全に監視できる。

スナップショットを上手に使う

　バックアップスナップショットは、データの迅速な保護と復元に対する企業の期待を満たす、有益で優れた技術だ。ただしスナップショットにはまだ不備な点があり、IT管理者が使い慣れた従来のバックアップツールのような、洗練されたインタフェースを備えていない。「重要なファイルの1日前のバージョン」を探すだけなら、検索能力が低くても大きな問題にはならない。だが「1年前に署名された契約書の、最終更新から数えて2番目のバージョン」を探すとしたら問題になる。

　スナップショットをバックアップに統合することは重要なデータ保護手順だ。コピーデータを作成し、保護データのインデックスを構築して一元管理するという代替手段もある。こうした手順を省略してはならない。