バックアップの進化がとまらない
数年間の停滞ののち、バックアップは様々な新技術の登場により黄金期に入った。
Storage Magazine 2016年10月号より
Brien Posey
つい最近まで、ほとんどの人にとってバックアップの実行は苦痛以外のなにものでもなかった。ITプロフェッショナルはおしなべて、バックアップの技術を陳腐で停滞したものと見なしていたし、彼らの上司の大半はバックアップを保険のようなもの、つまり災害が起こらない限り投資回収不能な支出、と考えていた。
しかし、5、6年の停滞を経て急速な技術革新により、今日のバックアップ製品はこれまででは想像もできなかったような機能を備え、ルネッサンス(再生)の時を迎えた。これらの新機能のなかには、災害が起こらなくても事業価値を生み出すものもある。バックアップ技術革新に影響を与えた動向は2つに大別できる。
・縮小が続くバックアップ・ウィンドウ
・サーバー仮想化の普及
バックアップ停滞期の終焉
従来のスケジュール型バックアップは、本質的に他の業務処理を邪魔する存在だった。多くの企業にとって、バックアップの実行は決して良い時間などではなかったし、たとえ他業務を妨害する懸念なく、夜間バックアップのスケジュールが組める贅沢な環境であっても、いずれはバックアップ・ウィンドウそのものが邪魔だ、という日が来るだろう。
多くの企業では日々データを蓄積しており、限られたバックアップ・ウィンドウの中でバックアップするにはあまりにも多くのデータが存在する。永久増分バックアップやグローバル重複排除などの技術によって、毎晩バックアップするデータ量を抑えたとしても、バックアップするデータ量がバックアップ・ウィンドウの枠からはみ出るのは時間の問題だ。
バックアップベンダーは、継続的データ保護を開発することにより、バックアップ・ウィンドウに関する問題を解消した。継続的データ保護は、画一的な夜間バックアップではできない、頻度の高い、ブロックレベルのバックアップを実現する。これにより、新規に作成されるか修正されたストレージブロックは、バックアップ・ターゲット(通常はストレージアレイ)に数分ごとにコピーされ、バックアップ・ウィンドウの必要性を完全に消し去った。
おまけとして、継続的データ保護は目標復旧時点(RPO)を大幅に短縮してくれる。従来の夜間バックアップであれば、約24時間かかるところだ。バックアップ頻度が少ない、こんなにも長いRPOでは、企業はほぼ1日分のデータを失う可能性がある。それに対し、継続的データ保護は、損失するデータの時間を5分以内にまで抑えることも可能だ。
サーバー仮想化は、バックアップ停滞の終焉に貢献した2番目に大きな技術動向である。仮想データセンターによって、物理サーバー環境では難しいか不可能だった方法でデータを保護し、復旧できるようになった。実際、インスタント・リカバリー技術を可能にしたのは、サーバー仮想化なのだ。
インスタント・リカバリー
バックアップと災害復旧(DR)の統合は、ここ数年データ保護の主要動向のひとつだった。バックアップは、システムやデータを必要に応じて戻せるポイント・イン・タイムのコピーとして存在している。一方、災害復旧は常に業務継続に主眼を置いてきた。災害復旧が目指しているのは、データ損失発生後のデータ復旧ではなく、電力の供給が停止した状態で基幹系システムを稼働し続けることである。
インスタント・リカバリーは、バックアップ、災害復旧ふたつの世界それぞれに最善の機能を提供することにより、両者を統合する。
従来のバックアップを苦しめてきた大きな問題の一つは、目標復旧時間(RTO)の長さである。別な言い方をすれば、バックアップ・データを戻すのには時間がかかる、ということだ。基幹系のシステムでは、長い復旧時間は許されない。インスタント・リカバリーは、サーバー仮想化の能力を活かして、復旧時間をわずか数分に短縮した。
インスタント・リカバリーの基本的な考え方は、ほとんど全ての継続的バックアップがそうしているように、ユーザーがディスク・ベースのバックアップを使っているのであれば、保護されている全ての仮想マシン(VM)のフルコピーは、バックアップしているストレージ・アレイ上に存在している、ということだ。
戻しが完了するのを待つことなく、VMをバックアップストレージ・アレイから直接マウントして、即座にサービスを開始できる。もちろん、VMのバックアップ・コピーを本番で使えば、バックアップ・データが書き変わってしまうという問題が起こる。インスタント・リカバリーは、VMのバックアップ・コピーが勝手に変更されないように、ハイパーバイザのスナップショットを使ってデータを保護している。
ハイパーバイザのスナップショットは元々、管理者がバックアップの戻しを行わなくともVMを以前の状態に戻せるように、ベンダーが付け加えた便利機能だ。管理者がVMのスナップショットをとると、ハイパーバイザは差分ディスクを生成する。VMの書き込み処理は全てこの差分ディスクにリダイレクトされる。つまり、VMの本来の仮想ハードディスクは変更されずに残るわけだ。インスタント・リカバリー機能を持ったバックアップ製品は、ハイパーバイザのスナップショットを利用して、VMのバックアップ・コピーを変更がかからない状態でオンラインにする前に、まずVMのスナップショットを作成する。VMが復活すると、従来型の戻しの処理が開始される。この処理では、VMは元の場所か別の場所へと戻される。戻しが完了すると、戻ったVMに差分ディスクの内容がマージされ、その後サービスが再開される。この時点でVMコピーはアンマウントされ、差分ディスクは削除されて、バックアップ処理は通常のオペレーションに戻る。
ほとんどのエンタープライズ・バックアップベンダーが、仮想データセンター向けにインスタント・リカバリーの機能を提供している。これらの機能はどのベンダーの製品でも似たり寄ったりだ。しいて言えばその違いは、サポートしているハイパーバイザの種類だ。例えば、Veritas NetBackupはVMware用インスタント・リカバリー機能を提供しているが、AcronisやVeeamはVMwareとHyper-V両方のインスタント・リカバリーが可能である。
インスタント・リカバリーのサンドボックス
インスタント・リカバリーによって、企業は仮想マシンのバックアップ・コピーをマウントして使えるようになった。これは、VMがものの数分でオンライン状態に戻れるということであり、復旧にはるかに長い時間がかかる従来のバックアップとは大違いだ。インスタント・リカバリーの主目的はVMのRTOを劇的に短縮することだが、いくつかのベンダーは、まったく同じ技術を使ってサンドボックス環境を生成する機能を付加している。
例えば、VeeamはVMをインスタント・リカバリーする仕組みを使って、本番環境を完全に模倣した仮想ラボ機能を提供している。これらの仮想ラボはバックアップサーバーで稼働しているため、サンドボックスになったVMはすでに使われている以上のストレージスペースを必要としない。仮想ラボは、パッチやOSのアップグレードあるいは新規アプリケーションのテストを行うのに便利な機能だ。
インスタント・リカバリーを拡張してサンドボックス環境生成機能を提供しているのはVeeamだけではない。例えば、Cohesityはコピーデータ管理機能によって、開発試験環境の生成ができるVMクローニング機能を提供している。
フラット・バックアップ
フラット・バックアップは、最近人気が出てきている別タイプのバックアップであり、ストレージ・スナップショットの生成とレプリケーションをベースにしている。機能的にはハイパーバイザのスナップショットに非常に似ているものの、ハイパーバイザ・レベルではなく、ストレージアレイ・レベルでストレージのスナップショットが生成される。つまり、フラット・バックアップはストレージ・レベルで行われるため、このバックアップはストレージ・ベンダーにサポートしてもらわなければならない。ストレージ・スナップショットはベンダー独自仕様であり、全てのストレージ装置にデフォルトでついている機能ではない。そのため、フラット・バックアップは全ての企業にとっての選択肢とはなりえない。特に、異機種のストレージ同士のバックアップではこれが顕著に現れる。それでも、EMCとHewlett Packard Enterprise (HPE)はフラット・バックアップをサポートしている。
継続的データ保護のような別手法のバックアップのほうが、フラット・バックアップよりも人気がある。主な原因となっているのは、フラット・バックアップのハードウェア要件、ベンダーごとの独自性、このような機能を持ったハードウェアの価格の高さ、などである。とはいえ、アプリケーションとの整合性機能を持ったスナップショットのおかげで、フラット・バックアップは市場の中で受け入られるようになってきた。比較的最近まで、ストレージ・スナップショットはアプリケーションの整合性ではなく、障害からの復旧を意識して設計されてきた。そのため、アプリケーション・サーバーの保護としては、ストレージ・スナップショットは適切な選択とは言えなかった。今日、EMC、日立データシステムズ、HPEなどのベンダーは、特定のアプリケーション用のストレージ・スナップショットを生成する機能を提供している。
フラット・バックアップは、ベンダーの固有性が少なくなれば、もっと人気が出てくるものと思われる。例えば、Veeamは自社のバックアップ製品一本で、様々なストレージ・ベンダーが提供するストレージ・アレイのスナップショットのバックアップとレプリケーション機能をサポートしている。ベンダー固有のストレージ・ハードウェアをサポートする、ということはVeeam製品が本当の意味で汎用ではないことを意味する。それでも、Veeamではより多くのストレージ・ハードウェアをサポートすべく、開発を続けている。
バックアップ・テスト
技術の進化がバックアップをより良いものにしたように、まさにこの同じ技術革新がバックアップのテストにも改善をもたらしている。長い間、バックアップ・テストとは、バックアップを元データと比較し、バックアップが正しく取られたかを検証することだといってよかった。しかし、検証はバックアップの整合性を保証してはくれない。
仮にWindowsサーバーからWinloadファイルが削除されたとする。このファイルは起動時の処理にしか使われないため、通常サーバーは正常に稼働し続ける。サーバーがバックアップされると、バックアップの検証は成功する。バックアップした内容が、サーバーのハードディスク上の内容と一致するからだ。しかし、万が一、バックアップ・データを戻した場合、重要なシステムファイルがバックアップに入っていないため、復旧したシステムは起動不能になるだろう。
Veeamのバックアップ・テストは普通のバックアップ検証を超える機能を持っている。事前に定義されたバックアップ・リカバリー検証テストを実行する際、VMのバックアップ・データはサンドボックス環境で起動された後、テストが行われる。自動的に行われるテストには、ハートビート、ping、アプリケーション・テスト、バックアップ・ファイル検証などが含まれている。この機能により、管理者はバックアップを機能レベルとファイルレベルで検証することができる。
バックアップ・アプライアンス
今日のバックアップ・ルネッサンスのもう一つの大きなトレンドは、バックアップ・アプライアンス導入の広がりである。バックアップ・アプライアンス、適用範囲と機能にかなり大きな幅があるが、一般的に(しばしば、テープライブラリをエミュレートして)バックアップ・ターゲットとして機能する専用ストレージ機器である。
通常、バックアップ・アプライアンスはディスク・ベースのストレージ機器であるため、どうしてもこれらをハードウェアと考えがちだ。たしかに、UnitrendsやVeritasなどのベンダーは物理バックアップ・アプライアンスを提供しているが、市場には仮想のアプライアンスも存在する。例えば、Amazon Web Serviceは、ユーザーが仮想バックアップ・アプライアンスを利用して、リソースをクラウドにバックアップできるようにしている。
また一方で、バックアップ・アプライアンスの機能も非常に多岐にわたっている。例えば、Veritasは自社のアプライアンスをマスターサーバー、メディアサーバー、あるいはその両方として使えるように設計している。これらのアプライアンスは、スナップショット・レプリケーション、ダイナミック・ストレージ 、WANアクセラレーションなどの機能を備えている。
Unitrendsは、インスタント・リカバリー機能を提供するために設計した、ハイパーコンバージド、オールインワン・バックアップ・アプライアンスを提供することで、他社とは少し違ったアプローチをしている。同社のRecovery Seriesアプライアンスは、アダプティブ重複排除、ローカル・アーカイビング、WAN最適化などの機能を搭載している。
バックアップは、かつては不可能と考えられた機能を提供するまでに進化してきた。さらに良いことには、バックアップの技術革新が一向に衰える気配がないことだ。例えば、将来のバックアップ製品は、様々な種類のクラウド・ベースのリソースのシームレスなバックアップに重点を置くことになりそうだ。かつてあれほどけなされたのに、今やこれほど活気に満ち必要不可欠になったバックアップに、これからどんなことが起こるだろうか?
われわれは、ほどなく新たな展開を見ることになる筈だ。
著者略歴:Brien PoseyはIT業界数十年の経験をもつMicrosoft MVP。前職は全国展開する病院・医療施設のCIO。