第8回　『永遠に差分バックアップだけ』ってどうして？

このコーナーでは、NetVaultをまったく使用したことがない方でも、ステップ毎に導入することができるよう、順を追って解説していきます。

今回は、NetVaultの目玉機能の一つである、Consolidate Incremental Backups Plugin（以下コンソリデート・インクリメンタル・バックアップ・プラグイン、または単にコンソリデート・プラグインと略します）の説明です。

※ちなみに題名の、『永遠に差分バックアップだけ』というのは少し誇大で、最低でも初回だけはフルバックアップが必要です。

今までご紹介したNetVaultの機能のフル活用のようなものなので、事前に次の環境構築作業および、今までの学習内容について確認を行っておいてください。

大容量のデータをバックアップする時に、以前に学習したような差分バックアップは、時間の短縮と、バックアップテープの容量の節約となります。ところが、差分を含むデータのリストアでは、差分の回数が増えれば増えるほど、リストア時間が長くなり、またメディア内のジョブ管理も分かりにくくなります。そのため、週に1回フルバックアップ、平日は差分バックアップというような運用が一般的です。

バックアップの対象クライアントが少ないうちはよいのですが、例えば1台のバックアップ・サーバで、10台のクライアントのデータをネットワーク経由でフルバックアップを行うとなると、予定された時間内にバックアップが完了するか分からず、LANトラフィックの増加による影響も心配になってきます。

そこで、少し考えて見ましょう。そもそも、差分のリストアができるのは、なぜでしょう？一般的には、フルバックアップをリストアし、その後、差分バックアップをリストアするからと言われています。ただしこの場合、一部のバックアップソフトウェアでは、フルバックアップ以降に削除されたデータが最終的に残ってしまうなどの現象が発生します。削除されたというステータスを認識できないためです。

NetVaultでは、バックアップのたびに完全なファイル・リストを作成するため、削除されたというステータスについても正しく認識し、リストア時には完全な状態でファイル・システムを構成することが可能です。

そして、このファイル・リストを使用することでより効果的なリストアを実現することができます。一般に、リストアを実行しなければならないということは、緊急性が高いオペレーションが要求されます。緊急性が高いのであれば、リストア時ではなく問題が発生していない平常時にその作業をあらかじめ行っておこう！というのがコンソリデート（日本語で言うと統合という意味です）になります。リストアの際には、そのままファイル・システムへデータを書き出しますが、コンソリデートの場合には、その対象が異なるドライブ上にマウントされたメディアということになります。

コンソリデートのもう一つの利点は、単に統合するだけでなく、統合したデータをフルバックアップのベースと使用し、その後の差分バックアップの基準とすることができます。そのため、極端な例で言えば、クライアントからのバックアップについて、初回のみフルバックアップを行い、その後は永遠に差分バックアップだけで運用することも可能になります。

もしコンソリデートのジョブ実行について、多少なりとも不安があるのであれば、例えばGFS方式をバックアップポリシーとして採用した際に、月に一回だけ行うGrandfatherの回だけ完全フルバックアップを行って、その他の週末はコンソリデートで対応するということも良い案でしょう。

この機能は、NetVaultをServerとしてインストールする時に、自動的にインストールされます。標準で備わっている機能ですのでそのままご使用いただけますが、ご使用にあたりいくつか条件があります。

データを統合するには、データを読み込みながら、他のメディアに複製します。そのため、最低2台以上のドライブが必要です。幸いなことに、物理的なテープ装置でなくとも、仮想テープ・ライブラリにより代用することも可能です。

また、コンソリデートの対象となるデータ形式で対応しているのは、Linuxおよびその他UNIXプラットホームに関してはFile System Pluginのみとなっています。（Windowsの場合には、Microsoft Exchange MailBox Pluginにも対応しています）

最後に条件ではないのですが、マシンが1台で自分自身のデータをコンソリデートするのは、クライアントのデータをコンソリデートするよりもメリットはぐっと減ります。クライアント・データのコンソリデートの場合には、ネットワーク経由でのトラフィックを激減させることができるという大きなメリットがありますが、サーバ自身のみのコンソリデートの場合には、単にデータの管理が見やすくなるということになります。また、コンソリデートは1つのバックアップジョブとして実行されるため、実行時にはバックアップ・サーバ側の負荷がかかります。あくまで、クライアント側の負荷をいかに楽にしてあげるかということに重きが置かれています。データ容量が非常に多い場合に有効なエンタープライズ向けの機能ということも言えるでしょう。

手順的には、前回のデータコピーに非常によく似ています。既にご説明している機能については、割愛しますので、過去の講座も振り返って参照してください。

まずは、準備として、テープにラベル/グループラベル設定を行い2種類のグループに分かれたテープを作成します。特にグループラベルを設定しなくてはいけないという決まりはありませんが、あらかじめ明示的な指定を行っておくことにより判別を容易にします。（差分用にテープを分け、3種類のグループにして確認することも可能ですが、分かりやすくするために2つとしました。分かる方は応用としてチャレンジしてみてください）

ここでは、"FullInc xx / FullIncGrp"というMIDおよびグループラベルに設定した最初にバックアップに使用するメディア、および"Cons xx / ConsGrp"という統合先となるラベルのメディアをそれぞれ5本設定しました。バルク・ラベルの機能を使用すると大量のテープへのラベル設定が簡単です。

次に、設定したグループラベルを指定して、データをバックアップします。

今回の設定は次のような状況を仮定して行います。

【オリジナルのバックアップ】

1. "/etc"の領域をバックアップ・セレクション・セットとして保存する
2. バックアップ・タイプは、"フル"に設定
3. スケジュールは"即時"
4. メディア指定として"FullIncGrp"のグループラベルを指定し、再利用メディアオプションを"全て"に設定
5. 詳細設定にて、世代管理を2フルバックアップとする。常にオリジナルは2世代保存になる

上記を設定後、バックアップを実行します。

次に、差分バックアップを行うために、"/etc"内のファイルを変更するか、新規ファイルを追加します。

差分状態を作り出すファイルを用意します。ここでは、単にtouchコマンドにより"/etc/test"以下にファイルを作成しています。

[root@demo1rh9 root]# cd /etc
[root@demo1rh9 etc]# mkdir test
[root@demo1rh9 etc]# touch ./test/test01

そして差分バックアップを実行します。

【差分バックアップ】

1. 保存された"/etc"を指定したバックアップ・セレクションセットを読み出す
2. バックアップタイプは、"インクリメンタル"に設定、 タイプは"最後のバックアップ以来"
3. スケジュールは"即時"
4. メディア指定として"FullIncGrp"のグループラベルを指定し、再利用メディアオプションを"全て"に設定
5. 詳細設定にて、世代管理指定せずそのままで使用する

再度差分状態を作り出すファイルを用意し、最終的に4回程度差分バックアップを行ってください。

[root@demo1rh9 etc]# touch /etc/test/test02
※test02の数字部分は回数につれて増加します。

差分バックアップの実行については、都度ジョブを作成せずに、ジョブ管理から、古い差分バックアップのジョブの右クリックメニューから"今すぐ実行"を選択してもよいでしょう。

メディア管理画面でセーブセットの状況を確認します。

以上で、準備が整いました。ここまでは以前に行った差分バックアップまでと一緒です。次に、早速コンソリデートを行ってみましょう。

まず、セレクションタブでどのコンソリデートを行うのか指定します。指定には2種類あり、1つはバックアップ・ジョブを基準に、過去に実行した結果に基づき指定した時点までのデータを統合するもの。

もう1つは、バックアップ・セット単位で、そのセットにとって最新のデータまでの統合を行う方法です。

一見、前者のバックアップ・ジョブの方が自由に選択できるので、優れている様に見えますが、過去に実行した結果に基づくというところに注意が必要です。これから実行される予定であるジョブは表示されません。そのため、スケジュール設定してフル・バックアップの代わりにしようするような場合には、バックアップ・セット単位にて指定する必要があります。バックアップ・ジョブ単位での指定は、スケジュールによらず、マニュアルでバックアップおよびオフサイト保管するような際に、柔軟性があるため便利です。

オプションタブには、何一つ項目はありません。

その他は、一般のバックアップ設定と同様です。
詳細設定の世代管理については、フルバックアップと同じように指定する必要があります。例えば、フルバックアップを2世代というポリシーにしていたのであれば、やはりここでも世代管理は2にする必要があります。

もう一度確認すると、今回は次のようになります。

1. Consolidate Incremental backupsを選択し、事前に定義した"linux etc"バックアップセットを指定する
2. スケジュールは"即時"
3. メディア指定として"ConsGrp"のグループラベルを指定し、再利用メディアオプションを"全て"に設定
4. 詳細設定にて、世代管理を2フルバックアップとする。常にフルバックアップとコンソリデートバックアップを含めて2世代は保存されていることになる

すべてのタブの設定を確認したら、実行します。

メディア管理にて、"FullIncGrp"と"ConsGrp"内のメディアに格納されたセーブセットを確認します。"etc fullbackup"として実行されたセーブセットは、残り世代数が1になっているのに対して、新たに生成された"etc consolidate backup"は残り世代数が2になっているのに注目します。

また、リストア画面では、コンソリデートのジョブが通常のフルバックアップや差分バックアップと同様にリストア可能なことが確認できます。

再度、差分テスト用のファイルを作成しながら、差分バックアップを実行します。

[root@demo1rh9 etc]# touch /etc/test/test05
※test05の数字部分は回数につれて増加します。

差分用のファイルを作成後、差分バックアップを実行します。
この作業を、test08まで行います。

そうすると、合計8つの差分バックアップがメディア管理に存在することになります。

ここで、再度コンソリデートを実行します。

古いコンソリデートをジョブをジョブ管理上で指定して、右クリックメニューから"今すぐ実行"により走らせます。

コンソリデートは、一番古いバックアップデータではなく、直近のコンソリデート・バックアップと比較し実行され、ジョブが完了すると一番古いフルバック・アップデータは、世代管理により残り世代数が0になったと判断されリタイアされます。

メディア管理で確認しても、フルバックアップおよび関連する古い差分バックアップのセーブセットはリタイアされています。

以上を繰り返すことで、クライアントからのバックアップを永遠に差分だけ取得することで運用が可能になります。そう思うと、安くなったブロードバンド回線を使用しインターネットの公衆回線網を使用してリモートバックアップなどの案もでてくることでしょう。実際に、ハードウェアベースのVPNを使用し本社と支社間を結びバックアップ統合を実現しているケースもあります。なお、コンソリデートを多用する場合には、バックアップ・サーバにかなりの負荷がかかることが考えられます。通常、バックアップ・サーバは昼間リソースが空いていますので、それらを鑑みながらシステム・スペック等を決定すると良いでしょう。

以上、今回はコンソリデートの使い方について一通り見てきました。最初はとっつきにくく思えるかもしれませんが、使って見るとDataCopyよりも簡単かもしれません。是非チャレンジしてみてください。