カスタマイズしたディレクティブの作成

「Directives」リソースを使ってディレクティブを作成し、これを「Clients」リソースを使って特定のクライアントに適用できます。環境はそれぞれ異なるので、すべてのケースに当てはまるディレクティブの作成規則というようなものはありません。ここでは、管理者の参考となるように、よく行われるカスタマイズの例をいくつか紹介します。

例 : Solaris クライアント上の特定のディレクトリをバックアップするためのディレクティブ

client123 のディレクトリ /aaa/zzz だけを保存する場合を考えます。ここではディレクティブを使って、Backup がディレクトリ /aaa と /zzz の中で、余分に他のファイルやサブディレクトリを検出し、バックアップさせないようにします。このディレクティブは null という UNIX アプリケーション固有のモジュール (uasm) を呼び出します。null を使用すると、指定されたディレクトリ内のファイルは除かれます。+null を使用すると、指定されたディレクトリ内のファイルと、それより下位の指定されたディレクトリ内のファイルは除かれます。/aaa/zzz だけをバックアップするためのディレクティブの内容は、次のようになります。

<< / >>
  uasm: 	aaa
  null: *.?
<< /aaa >>	
  uasm: zzz
<< /aaa/zzz >> 
  +uasm: *.?*

別の例として、root 以外のすべてのマウントされたディスクと、root 以外のディスクの /home および /users ディレクトリをバックアップする場合を考えます。また、これ以外にも cron ファイルとカレンダーデータベースもバックアップします。各クライアントについて、「Save Set」属性の値は「All」になっています。この場合のディレクティブは次のようになります。

<< / >>
  uasm: home users var
  null: *.?*
  +null: core
<< /home >>
  +compression: *.?*
  +null: core
<< /users >> * 
  compression
  +null: core
<< /var >>
  uasm: spool
  null: *.?*
  +null: core
<< /var/spool >>
  uasm: calendar cron
  null: *.?*
  +null: core
<< /var/spool/calendar >>
  +compression: *.?*
  +null: core
<< /var/spool/cron >>
  +compression: *.?*
  +null: core
<< /cdrom >>
  null: *.?*
<< /opt >>
  null: *.?*
<< /tmp >>
  null: *.?*
<< /usr >>
  null: *.?*

ディレクティブの一部に null を使用すると、特定のバックアップの際に、指定したファイル (複数の場合もある) は保存されませんが、Backup が作成するインデックスリストにはそのエントリが追加され、それらのファイルがバックアップ操作に含まれていたことが示されます。指定したファイルはインデックスに含まれているので、そのファイル名はディレクトリ内で表示可能となり、Backup から見たファイルシステムの様子は、実際のファイルシステムとまったく同じになります。つまり、最新のバックアップでは除外されていて、復旧に使われるデータが他のファイルのデータよりも古いものであっても、recover プログラムの GUI には、復旧に使われるファイルとして表示されることになります。

この動作は、ディレクティブに skip という uasm を使った場合の処理とはいくぶん異なります。skip という uasm を使用すると、ブラウザには、実際のファイルシステムに類似のものでなく、実際にバックアップされたデータだけを反映したファイルシステムのビューが表示されます。したがって、技術的な利点の面からも、skip よりも null を使用することをお勧めします。

バックアップコマンド

「Clients」リソースには、追加処理を指定するためのカスタマイズしたバックアップコマンドを入力できます。このカスタマイズしたバックアップコマンドは、スケジュールされたバックアップが開始されるときに、デフォルトの save プログラムの代わりに使用されます。

savepnpc プログラムを使うと、クライアントバックアップ 1 回ごとに一度ずつ前処理コマンドと後処理コマンドを実行することができます。savepnpc プログラムは save プログラムと同様に、ファイルを長期保存用のストレージに保存します。savepnpc は、クライアントに対して最初の保存操作を実行する前に、/nsr/res/<group_name>.res ファイルに含まれている前処理コマンドをすべて実行します。また、クライアント上で最後の保存操作が完了した後に、/nsr/res/<group_name>.res ファイルに含まれている後処理コマンドをすべて実行します。savepnpc の詳細は、「savepnpc 」と savepnpc のマニュアルページを参照してください。

Backup がクライアントファイルシステムのデータをバックアップする方法に影響を与えるような追加プログラムを作成することによって、クライアントバックアップをカスタマイズできます。

たとえば、Backup がバックアップ操作を実行する前にメールサーバーやデータベースを終了し、バックアップが完了したあとにこのメールサーバーやデータベースを再起動するプログラムを作成できます。あるいは、バックアップ操作が開始される前にメッセージ (「backup started at 3:33 a.m.」など) を出力し、クライアントデータのバックアップを実行し、バックアップが完了した時点でメッセージ (「backup completed at 6:30 a.m.」など) を出力するようなプログラムも作成できます。

バックアップコマンドは、そのクライアントに対して定義されている各セーブセットに対して実行されるのであって、クライアントごとに実行されるわけではありません。管理者がセーブセット値として「All」を指定すると、バックアップコマンドのバッチファイルはクライアント上のファイルシステムの数だけ実行されます。カスタマイズしたバックアップコマンドの最も単純な例として、「Save Set」属性に単一のセーブセットを指定して特別なクライアントを作成する手法があります。

使用している環境に最も合ったカスタマイズレベルを考える際には、次の事柄を検討してください。

• 使用できるディスク容量

• 毎回バックアップする必要がないクライアントデータの有無 (たとえば企業内の電子メールなど)

• Backup が実行したバックアップに関して、(セーブグループ完了レポート以外にも) 特殊メッセージの送信の必要性

savepnpc とは異なり、カスタマイズしたバックアップコマンドの新しいインスタンスは、標準の保存プログラムと同様に、「Save Set」属性に指定されている個々のセーブセットごとに起動されます。データベース用のカスタマイズしたバックアップコマンドで「Client」リソースを作成するときには、この点に注意してください。指定された個々のセーブセットごとに、シャットダウンコマンドが実行されます。