ActiveImage Protector Technical Preview版の重複排除圧縮とは?

ActiveImage Protector v3.5  Technical Preview版

10/21に開かれたvForum 2011でActiveImage Protector v3.5 の Technical Preview版を展示しました。TP版の目玉は重複排除圧縮機能です。重複排除あるいは重複削除は、最近ストレージに搭載されて話題になっている機能です。この重複排除をバックアップファイルに対して行い圧縮して保存容量の削減をねらうのがAIPの「重複排除圧縮」です。複数の仮想ディスクやサービスパックのロールバック用ファイルなど重複するデーターは意外に沢山あります。

重複排除とは?

「重複排除」は言葉通り、重複したものを排除して保存しない、ということです。では、なにをもって重複とみなし、どうやって排除するのでしょうか?一番簡単な例としては、AIPにはありませんが、重複ファイル削除という機能でしょう。ファイル名やファイルの内容を比較して同じものを見つけたらどちらかを削除する、というものです。Windowsのクリーンナップやパフォーマンスアップユーティリティによく搭載されています。単にだぶっているファイルを削除するだけですので、本当に必要かどうかはユーザーの管理になりますし、間違って消してしまったときに元に戻すのは、元の場所にコピーするだけとはいえ、元の場所を確認したりと案外手間がかかります。

次に、バックアップでの重複排除があります。まず、ファイル単位で、バックアップアップ時に重複しているファイルはリンクなどに置き換えて、復元時には自動的に元に戻す、というものです。

もうすこし高度なものになると、各ファイル内の重複している部分(ブロック)を較べて、同じ内容のブロックがあればFinger Printをつけてインデックス化して行きます。こうすることで、同じFPを持っているブロックは同じ内容ということがわかるのでバックアップ対象から排除、あるいは削除できます。これと同様のことをストレージ上で行えば、重複排除機能付のストレージということになります。ストレージにファイルを保存する時にFPをつけて既に保存してあるファイルのものと比較して重複排除を行うわけです。

そして、ストレージ、メディアサーバーベースの重複排除があります。これは、バックアップをしたものに対して既存のバックアップファイルとの比較をする「ポストプロセス」で行うのが通常です。最終的には容量は削減できますが、重複排除を処理する時間とバックアップファイルのための容量(比較先と比較元)が一時的に必要になります。保存時に重複排除を「インライン」で行えるストレージはハードウェアレベルでのサポートが入るので高速で一時的な容量も必要ありませんが、非常に高価な機器になってしまいます。

ActiveImage Protector の重複排除圧縮

AIPの重複排除圧縮は、バックアップ時にインラインでブロック単位の重複排除を行い圧縮をかけます。これで大幅にバックアップイメージファイルのサイズが縮小できます。バックアップ対象のボリュームあるいはディスクのバックアップをしながら重複を排除して圧縮をかけていきます。

さて、最初のバックアップが終わってもバックアップは終わりではありません。データーは常に更新されているのでスケジュールバックアップを行うのが一般的です。次回バックアップ時、ストレージレベルのポストプロセスではバックアップ取得後に重複排除を行うわけですが、AIPでは元々増分バックアップができるので変更部分だけをバックアップできます。毎回フルバックアップを行う必要はありません。

効果を測定

では、実際にどの程度小さくなるのでしょうか?vForum 2011(2011/10/20)に展示した参考出品したバージョンでの計測です。ターゲットマシンには仮想マシンを3台作成してあります。

重複排除計測データ

重複排除計測データ

高圧縮から更に30%程度圧縮できているのがわかります。所要時間は高圧縮の場合とほとんど変わりませんでした。他社製品の高圧縮も参考までに計測しましたが、圧縮アルゴリズムが似通ったものだからか、AIP v3.1(現行バージョン)を含めてほぼ同程度のサイズに収まっているのは興味深いところです。現行製品にくらべて30%程度のストレージの節約というのは相当の改善と言えるのではないでしょうか。

ActiveImage のイメージ管理

バックアップファイルをどう管理していくのか

バックアップしたファイルをどう管理していくのか、というのはバックアップソフトを使っている以上必ず悩まされる問題です。ActiveImage Protectorはスケジュールに基づいた増分バックアップができます。増分はファイルサイズも小さく、バックアップ時間もかなり短いので常用する機能です。

増え続ける増分ファイルをどうするのか

増分は、ベースとなるフルバックアップと合せて「イメージセット」という概念で管理します。各イメージセットは「世代」として扱います。スケジュールで古い世代から自動的に削除することで、バックアップ保存先の容量不足を抑えられるようになっています。バージョン3.1からは世代管理ではなく、最初のフルバックアップ以降はずっと増分を取りつづけらるようにもなりました。

日々のバックアップにはとても便利な増分バックアップですが、ファイル数が多くなってしまうのが悩みどころです。たとえば、営業時間中(8時間)に一時間毎に増分を作成すると、一日に8個、一週間(営業日を5日)で40個、一ヶ月で約160個の増分バックアップファイルが追加されます。個々のサイズは小さいので容量はあまり心配ではありませんが、ファイルはかなりの数になります。

実際に復元する時のことを考えると、そこまで細かい精度で全ての状態を保存しておきたい、ということも少ないのではないでしょうか?たとえば、1週間分は増分を保存しておいて、それ以前のものはまとめてしまえば、復元するときに目的のバックアップファイルを探しやすくなります。

増分をまとめる―ユニファイドとコンソリデーション

1つのイメージセットは1つのベースファイルと複数の増分ファイルでできています。増分ファイル名は命名規則に従ってbasename_d01_0001_0001.aii というような形になります。ベースネームの後ろはディスク番号、ベース番号、増分番号となっていますが、数が増えてくると管理も大変になります。復元する際はたいだいは最新のものを使うことが多いかと思います。もちろん最後のファイルを選べばよいのですが、100個のファイルをスクロールしなければならない状況になってくると、正直使いづらいです。

こうした沢山の増分ファイルをまとめてしまうのが、ユニファイドとコンソリデーションです。

ユニファイドは、フルバックアップと全ての増分をまとめて1つのバックアップファイルにします。まとめて1つのバックアップイメージファイルになるわけです。復元はこのバックアップファイルをひとつ選べばOKです。

■(ベース)□□□□□□□□(増分) →  ■(ベース)

コンソリデートは、増分を全部1つにまとめる機能です。この場合は、ベース(フルバックアップ)と1つの増分ファイルになります。どちらを使えばいいかは、状況次第です。

■(ベース)□□□□□□□□(増分) →  ■(ベース)□(増分)

もちろんどちらの場合でも、引き続き増分バックアップを継続できます。
3.1の新機能、継続増分バックアップと併用すれば、より効率的なバックアップを行うことができます。

ActiveImage 3.1 の見どころ

ActiveImage 3.1 がリリースされました。

AIP 3.1 バナー

ActiveImage Protector 3.1

3.0から3.1というとポイント.1のマイナーバージョンアップですが、思っていたより強化ポイントが盛りだくさんのアップデートになりました。今回の主な新しい機能は、

  • オフサイト レプリケーション
  • 増分バックアップの継続とリコンサイル
  • リモート管理の強化

です。

バックアップするだけではなく、バックアップ後のイメージファイルの取り扱いやリモートコンピュータの管理といった、エンタープライズ向けにより使いやすく機能を強化したと考えてもらればよいかと思います。
続きを読む…

MySQL のイメージバックアップ – ActiveImage Protector 3.1 Linux Edition

ActiveImage Protector 3.1 Linux Edition リリース

ActiveImage Protector のLinux 版 バージョン3.1がリリースされました。

Linux EditionはイメージングバックアップのActiveImageのLinuxネイティブ版になります。
主な特長は

  • Linuxネイティブ
  • ボリューム単位の高速バックアップ
  • ext 3, 4のホットイメージングバックアップが可能
  • 未使用領域をバックアップしないスマートセクター
  • LVMに対応

となっています。

今回の3.1の見どころは

  • Red Hat Enterprise Linux 6.0/6.1 に対応
  • MySQLへの対応

となっています。
今回のバージョンアップでの一番のウリはMySQLが稼働しているサーバーでのホットバックアップが可能になったことでしょう。

続きを読む…