test

Solstice Backup 5.1 管理者ガイド

第 3 章 サーバーとストレージノードの操作

この章では、Backup サーバーによって管理する、次の操作について説明します。

この章は次の節で構成されています。

クライアント/サーバー通信の構成

Backup サーバーとそのクライアントの間の通信は、「Server」リソースと「Clients」リソースに入力されている構成値によって指定されます。Backup がデータを保護し、セキュリティを保証する機能を実現するためには、ネットワークの構成が完全かつ正確に指定されている必要があります。

各クライアントリソースには、Backup 管理プログラムの「Clients」リソースの「Aliases」属性に、ドメイン名サービス (Domain Naming Service, DNS) のショートネームとロングネームの両方が含まれていなければなりません。

「Clients」リソースで Backup クライアントを設定する方法については、「新しい Backup クライアントの構成」を参照してください。

Backup に影響を与えるネットワーク通信の問題を診断する方法については、「クライアント/サーバー間通信」を参照してください。

アクセス権の管理

サーバーのリソースはユーザーがクライアントマシンで表示できますが、Backup サーバーの構成の追加や変更は、「Server」リソースの「Administrator」属性に指定されているユーザーだけが行うことができます。Backup がインストールされた時点では、Backup 構成を変更する権限を持っているユーザーは root@server-name だけです。管理者のリストに他のユーザー ID やマシン名を追加するには、Backup サーバーマシンでスーパーユーザーになり、「Server」リソースの「Administrator」属性にユーザー ID を追加します。

「Administrator」属性では以下のエントリを使用できます。

(これらのエントリを、nsradmin インタフェースを使用して入力するときには、コンマで区切ります)。

また、個々のクライアントについて、ユーザー特権を追加したり制限したりできます。詳細は、「他のクライアントにリモートアクセス権を与える方法」を参照してください。

注意 - 注意 -

Backup の「Administrator」属性にユーザーを追加した場合、そのユーザーは、その Backup サーバーに対する Backup 管理特権だけを持つことになります。Backup の「Administrator」リストに属するユーザーは、Backup サーバーマシンや、ネットワーク上の他のマシン上でのスーパーユーザー特権を自動的に得るわけではありません。Backup 管理者は、Backup サーバーのクライアントやその他のリソースの属性を変更できますが、クライアントデータに対して、バックアップや復旧のための特別な権利を持っているわけではありません。

ストレージノードの構成

ストレージノードは、Backup サーバーと、Backup のバックアップ、アーカイブ、および HSM 操作に使われる 1 台以上のデバイスに接続されているマシンです。ストレージノードに接続されているデバイスは、制御元の Backup サーバーに物理的に接続されているわけではないので、リモートデバイスと呼ばれます。ストレージノードはデバイスを制御するための特別な Backup ソフトウェアを実行しています。リモートデバイスのメディアに格納されているデータは、制御元の Backup サーバーのメディアデータベースとオンラインクライアントファイルインデックスによって追跡されます。

Backup 構成にストレージノードを追加することにより、Backup サーバーのパフォーマンスが改善され、ネットワークを設計する際の柔軟性が高まり、データ管理処理の制御を 1 台または少数の Backup サーバーに集中させることができます。

ストレージノードを作成するには、Backup 配布ソフトウェアのストレージノードバイナリファイルをストレージノードマシンにインストールします。次に、ストレージノードのデバイスを定義します。デバイスの定義方法については、「リモートデバイスの構成」で説明しています。

ストレージノードのホスト名は、ストレージノード上で jb_config プログラムと scanner プログラムを実行する予定がない限り、サーバーの「Administrator」属性に指定する必要はありません。この属性に指定する場合のエントリは root@storage_node_hostname になります。

オートチャンジャやサイロの場合には、jb_config プログラムを使ってデバイスを定義する前に、ストレージノードのホスト名を「Administrator」属性に追加する必要があります。jb_config プログラムが終了したら、「Administrator」属性のリストからこのストレージノードのホスト名を削除できます。ただし、後で新しいオートチェンジャを構成する必要が生じた場合には、ストレージノードのホスト名を「Administrator」属性に追加してから jb_config プログラムを実行し直さなければなりません。「Administrator」属性にストレージノードのホスト名を追加すると、ストレージノード上で、そのノードが制御しているデバイスごとに nsrmmd プロセスのインスタンスが 1 つずつ起動されます。

既存の Backup サーバーのストレージノードへの変換

既存の Solstice Backup サーバーをストレージノードに変換できます。既存の Backup サーバーをストレージノードに変換するには、次の操作を行います。

  1. 現在使用している環境の最新のバックアップコピーを取っていることを確認します。

  2. サーバーを Solstice Backup 5.1 に更新またはアップグレードします。

    Backup Server Edition ソフトウェアを使用しているサーバーの場合は、Backup Network Edition 5.1 にアップグレードする必要があります。

  3. 1 台のサーバーを制御元の (マスタ) Backup サーバーとして選択します。

  4. この新しいマスタサーバーを構成して、他のサーバーをストレージノードとして使用できるようにします。ストレージノードの /nsr ディレクトリを管理します。

    ストレージノードのイネーブラについては、ライセンスセンターにお問い合わせください。米国では +1-800-872-4786 (メニューで #3 を押します) に電話してください。その他の国では、ライセンスセンターの Web ページ http://www.sun.com/licensing を参照してください。

  5. 復旧プロセスの過程で、変換を行なった日付に注意します。

  6. 変換の日付よりも前にバックアップされていたデータを復旧します。

    このためには、必要なデータを含んでいるマシン上で nsrd プロセスを起動し、ストレージノードを Backup サーバーに変換します。また、ジュークボックスやライブラリなどの自動化デバイスがサーバーに接続されている場合には、これらのデバイスのインベントリを作成します。

  7. データの復旧が終了したら、nsrd プロセスを終了させてシステムをストレージノードに戻し、ジュークボックスやライブラリのインベントリを作成します。

注意 - 注意 -

Backup サーバーとストレージノードサーバーのリソースデータベース、メディアデータベース、およびクライアントファイルインデックスをマージしないでください。マージすると矛盾が生じる場合があります。

Backup サーバーから、その Backup サーバーに関連付けられているストレージノードが制御しているリソースを見ることができます。さらに、管理者はローカルデバイスとリモートデバイスについてのすべてのストレージ操作 (マウント、マウント解除、ラベル付け、インベントリ作成、ボリューム、プール、デバイス、オートチェンジャ、クローン作成、および nsrjb) を実行でき、またすべての Backup クライアント操作の定義と制御ができます。

1 台の Backup サーバーで複数のストレージノードサーバーを制御できます。クライアントと、ストレージノードの優先リストとの間にアフィニティを設定することで、クライアントを特定のストレージノードにバックアップできます。この種のクライアントアフィニティは、制御元の Backup サーバーのリソースデータベースに保存されます。

Backup 構成にストレージノードを追加することにより、Backup サーバーのパフォーマンスが改善され、ネットワークを設計する際の柔軟性が高まり、データ管理処理の制御を 1 台または少数の Backup サーバーに集中させることができます。

スケジュールされたバックアップの構成

この節では、自動的なグループバックアップとカスタマイズ可能なバックアップスケジュールなどの、Backup のスケジュールされたバックアップの機能を設定する方法について説明します。

バックアップグループの構成

Backup のバックアップグループを使うと、クライアントのバックアップの開始時刻を指定できます。クライアントセーブセットをバックアップグループに割り当てて、どのクライアントセーブセットをいつバックアップするかを指定できます。また、クライアントのセーブセットを複数のグループに割り当てることも可能です。

クライアントマシンの数が特に多い場合は、ネットワークトラフィックを軽減するために、開始時刻が異なる複数のグループを作成することを検討してください。たとえば、エンジニアリング部門のマシンを含むグループのバックアップを朝の 4 時に開始し、ネットワーク上のこの部門以外の全クライアントを含むグループのバックアップを真夜中に開始することもできます。

複数のグループを作成する場合は、サーバーの負荷が高くならないように、開始時刻をずらします。1 つのグループがバックアップを終える前に次のグループが開始することのないように、十分な間隔をあけてください。Backup は、先に開始したグループがすべて終了するまでは、次のグループのバックアップを開始しません。「例 : 大規模なクライアントファイルシステムのスケジュール」を参照してください。

グループを新たに作成するには

Backup にはいくつかの事前構成済みのグループがあります。これとは異なるグループ構成が必要な場合は、状況に合わせて新しいグループを作成できます。独自のグループをカスタマイズして作成し使用するには、次の操作を行います。

  1. 「Groups」リソースにグループを作成します。

  2. 「Pools」リソースで既存のプールを編集するか、新しいプールを作成します。「Groups」属性で新しく作成したグループを選択します。

  3. 「Clients」リソースで、グループに入れたいセーブセットを含んでいるクライアントマシンのクライアントリソースを編集または作成します。「Groups」属性で新しく作成したグループを選択します。

    注意 - 注意 -

    グループ名にはスペースは使用できません。

Backup によるバックアップグループの使用方法

各バックアップグループの中のクライアントセーブセットは、指定されたグループの開始時刻にスケジュールされたバックアップを自動的に開始します。個々のグループにどのクライアントを入れるかを決めるときに、クライアントのバックアップスケジュールを考慮することで、バックアップの負荷を調整できます (個々のクライアントがフルバックアップを行う日をずらすようにスケジュールを作成する方法については、「スケジュールの構成」を参照)。

図 3-1 に、Backup がバックアップグループを使って複数のクライアントセーブセットをバックアップする方法を示します。

図 3-1 Backup がグループを使って複数のクライアントをバックアップする方法

Graphic

この例では、Oak、Elm、および Fir の 3 つのクライアントマシンが、真夜中にスケジュールされたバックアップを自動的に開始する Weekly Full というグループに属しています。クライアント Oak は毎月曜日にすべてのセーブセットのフルバックアップを、その他の曜日には差分バックアップを行います。クライアント Elm は火曜日にすべてのセーブセットのフルバックアップを、その他の曜日には差分バックアップを行います。クライアント Fir は水曜日にすべてのセーブセットのフルバックアップを、その他の曜日には差分バックアップを行います。各クライアントはフルバックアップを別々の曜日に行うので、サーバーに過度な負荷がかかることはありません。

第 2 のグループ Accounting は、クライアントを部門ごとにグループ化する例を示しています。Accounting グループには、クライアントマシン Birch と Pine があり、経理部門のマシンがバックアップできるようになる 7:00 p.m. にバックアップを開始します。この 2 台のクライアントマシンは同じ曜日にフルバックアップを行いますが、Pine はセーブセット /usr/home だけをバックアップするようにスケジュールされているのに対し、マシン Birch ではすべてのセーブセットがバックアップされます。バックアップに要する時間を推定することで、次のグループの開始時刻をいつに設定すべきかがわかります。

各グループのセーブセットは、ストレージデバイスにマウントされている適切なボリュームに書き込まれます。Backup はボリュームのプールを使ってセーブセットの編成、追跡、および格納を行い、グループを使って各クライアントがスケジュールされたバックアップをいつ開始するかを指定します。

Backup のデフォルトグループ設定

Backup には「Default」という名前の事前構成済みのグループがあります。Backup は、すべてのデータがバックアップされるように、すべてのクライアントを自動的に「Default」グループに追加します。ただし、Backup でデフォルトグループをバックアップするためには、このグループを有効にする必要があります。各クライアントを、必要に応じてこの「Default」グループに残すことも、カスタマイズしたグループ (複数でもよい) に入れることもできます。

「Start Time」属性と「Autostart」属性は、重要です。「Default」グループの「Start Time」属性は、毎日のバックアップを 3:33 a.m. に開始するように設定されています。この「Start Time」属性は変更できます。「Default」グループに限らず、Backup にあるグループに対してスケジュールされたバックアップを実行するためには、そのグループの「Autostart」属性を有効にする必要があります。

「Client Retries」

Backup サーバーがクライアントに接続できない場合、「Groups」リソースの「Client Retries」属性で、サーバーがクライアントへの接続を試みる回数を指定します。この回数だけ再試行を行なった後は、接続は失敗したと見なされます。(少なくとも) すべてのクライアントに交信してから、最初の再試行が行われます。「Groups」リソースの「Inactivity Timeout」属性は、クライアント上でバックアップが確実に行われるまでの Backup サーバーの待機時間を分単位で指定します。サーバーがバックアップ実行情報を受け取らないまま、この属性で指定されている時間が経過すると、サーバーはそのセーブセットのバックアップ操作を放棄します。

注 -

放棄されたセーブセットのバックアップが終了していても、savegrp が自動的に作成するレポートには、バックアップが完了したとは報告されません。たとえば、クライアントがネットワークファイルシステム (Network Filesystem, NFS) 接続経由でバックアップ中に NFS サーバーがクラッシュしてリブートした場合、Backup のバックアップ処理はハングアップし、タイムアウトとなります。Backup サーバーはこのセーブセットを「放棄された」としてマークしますが、バックアップ操作は NFS サーバーが再起動した時点で続行され、完了します。

「Default」グループの事前構成済みの属性値については、「「Groups」リソース」で説明しています。「Default」グループの属性はいずれも変更できますが、このグループそのものは削除できません。ただし、グループは必要に応じていくつでも作成または削除できます。

グループスケジュールを使ってクライアントの通常のバックアップスケジュールを変更する方法

グループの「Level」属性と「Schedule」属性を使って、クライアントの通常のバックアップスケジュールを変更できます。たとえば、クライアントの通常のバックアップスケジュールとは関係なく、適切な日にグループ内のすべてのクライアントのフルバックアップを行うことが可能です。「Level」属性で指定したエントリは、グループ内の各クライアントのバックアップレベルの設定値よりも優先されます。

あるいは、複数のクライアントに、各クライアントの個々のスケジュールではなく、同じバックアップスケジュールをグループとして適用することもできます。複数のクライアントのグループに、個々のクライアントのスケジュールではなく、デフォルトのスケジュール (毎日曜日にフルバックアップ) を設定できます。グループの「Level」属性と「Schedule」属性が空白になっている (事前構成済みの設定値) と、クライアントは個々のバックアップスケジュールに従います。

グループバックアップの監視と管理

Backup 管理プログラムの「Group Control」ウィンドウを使うと、バックアップ中に、スケジュールされたグループを監視できます。「Group Control」機能、セーブグループ完了メッセージ、ブートストラップの出力、およびシステムコンソールログなどの機能によって、スケジュールされたバックアップの成否と、データの復旧に必要な情報が得られます。

「Group Control」機能は状態情報を提供するもので、、スケジュールされたバックアップグループのプレビュー、停止、および開始のためのコントロールが用意されています。

最も新しく開始されたバックアップグループに関しては、次のいずれかの状態情報が表示されます。

動作の監視

Backup 管理プログラムの「Group Control Details」機能を使うと、完了したグループバックアップに関する詳しい情報を表示できます。この機能を使って、どのクライアントセーブセットがバックアップに成功し、どのセーブセットが失敗したのかを知ることができます。

「Group Control Details」 ウィンドウは、バックアッププロセスにおけるクライアントセーブセットの状態を、次の 3 つのメッセージフィールドのいずれかに表示します。

「Group Control Preview」機能を使うと、特定のグループのバックアップのシミュレーションを行えます。この機能により、Backup がグループバックアップを実行する前に、どのような問題が起こりうるかを知ることができます。Backup 管理プログラムでバックアップグループのプレビューを行うには、「Group Control」ウィンドウを表示し、「Preview」ボタンをクリックします。バックアップグループをコマンド行からプレビューするには、Backup サーバーでスーパーユーザーになり、シェルプロンプトで savegrp -p group-name コマンドを入力します。

Backup は、完了したグループバックアップに関する過去の情報ではなく、次のスケジュールされたバックアップの際にグループのバックアップがどのように実行されるかという情報を表示します。

スケジュールされたバックアップグループをただちに開始する方法

スケジュールされたバックアップグループを必要に応じて手動で開始すると、Backup は次のスケジュールされたバックアップのレベル (フル、レベル [1〜9]、差分など) でバックアップを実行します。

グループバックアップをただちに開始するには、次の 2 つの方法があります。

「Start Now」コントロールを使用すると、Backup は「Groups」リソースでスケジュールされている開始時刻を無効にし、グループ内のクライアントのバックアップをただちに開始します。

スケジュールされたバックアップグループの停止と再開

「Group Control」ウィンドウで「Stop」をクリックすると、Backup は現在行われているセーブセットのバックアップを完了し、残りのセーブセットのスケジュールされたバックアップを停止し、「Group Control」 ウィンドウの「Status」フィールドに「Not Finished」と表示します。

「Group Control」ウィンドウで「Restart」をクリックすると、Backup はそのグループのスケジュールされたバックアップを再開し、「Status」フィールドに「Running」と表示します。

スケジュールされたバックアップの際のオープン状態のファイルの管理

スケジュールされたバックアップの過程で、クライアントがオープンしているファイルが変更された場合、変更前バージョンのファイルがバックアップされ、これらのファイルが変更中であることが通知されます。「Group Control Details」ウィンドウには、次のような警告メッセージが表示されます。


warning: file filename changed during save

ファイルに対して行われた変更内容はバックアップされません。変更されたファイルをバックアップするには、バックアップグループを再起動するか、あるいは次のスケジュールされたバックアップの際に Backup でクライアントをバックアップします。

セーブグループ完了メッセージ

バックアップが完了すると、Backup はスケジュールされたバックアップが正常に終了した旨のレポートを出力します。Backup はスーパーユーザーに対して自動的に通知を送信し、Backup 管理プログラムにも同じ情報を表示します。

ブートストラップの生成と出力

バックアップグループに Backup サーバーからのデータが含まれていると、Backup は、サーバーファイルインデックス、メディアデータベース、および構成ファイルを含む、ブートストラップと呼ばれる特別なセーブセットを生成します。ブートストラップ情報は障害復旧に必須です。デフォルトでは、ブートストラップは Backup サーバーのデフォルトプリンタを使って印刷されます。デフォルトプリンタを変更するには、「Groups」リソースの「Printer」属性を変更します。

このブートストラップの出力は、サーバーを含むグループに対するスケジュールされたバックアップの際に、あるいはそのサーバーがアクティブグループに属していなければ、他のスケジュールされたバックアップのあとに作成されます。ブートストラップの出力は、スケジュールされたバックアップが自動的に開始された場合も、手動で開始された場合も生成されます。

ブートストラップをファイルに保存するには

ブートストラップは、ファイルに保存したり、1 つまたは複数のユーザー ID に対して電子メールで送信したりできます。

  1. nwadmin を実行し、「Customize」メニューで「Notifications」を選択します。

  2. 「Bootstrap」を選択します。

    「Action」属性が表示されます。


    /usr/bin/lp -s -c -t bootstrap -d%PRINTER

  3. ファイルを保存するには、これを次のように変更します。


    /bin/cat >> /directory/filename

  4. ブートストラップファイルを複数のユーザー ID に電子メールで送信するには、この行を次のように変更します。


    /usr/ucb/Mail -s "nwserver bootstrap" user-name@corp.com

システムコンソールログ

UNIX システムログには Backup から渡されたメッセージが表示されます。Backup をインストールすると、構成ログファイル (syslog.conf) に、システムログ機能がどのファイルやユーザーに、どのタイプの通知を行うかを指示する行が追加されます。次に例を示します。


daemon.notice                   /dev/console
daemon.notice                   /nsr/logs/messages
daemon.notice                   operator
local0.notice                   /nsr/logs/summary
local0.alert                    root, operator

スケジュールの構成

Backup サーバーは、各クライアントに割り当てられているバックアップスケジュールに基づいて、ネットワーク上の各クライアントシステムのバックアップされるデータの量を判断します。これらのスケジュールは、ユーザーの環境に応じて、単純にも、複雑にもなります。すべてのクライアントが同じスケジュールを共有することも、各クライアントが独自のスケジュールを持つこともあります。「Schedules」リソースを使用して独自のスケジュールを作成し、「Clients」リソースを使ってこのスケジュールをクライアントセーブセットに適用してください。「Clients」リソースとクライアント構成の詳細は、第 5 章「Backup クライアントの操作」を参照してください。

Backup によるバックアップスケジュールの使用方法

Backup は、クライアントのバックアップスケジュールを使用して、指定されたセーブセットに対して、特定の日に、どのレベルのバックアップ操作を行うべきかを決定します。バックアップ操作が開始される日付は、そのクライアントセーブセットが関連付けられている「Group」リソースに割り当てられている「Start Time」属性によって決まります。

Backup は 4 つのタイプのバックアップレベルをサポートしています。

(バックアップレベルの詳細は、「バックアップレベル」を参照してください)。

「Schedules」リソースを使うと、必要に応じてバックアップスケジュールをカスタマイズできます。たとえば、一部のクライアントに対しては、3 日おきに「フル」のレベルでバックアップを行い、それ以外の日は差分バックアップを行います。その他の、重要性が低いデータを含んでいるクライアントに対しては、1 か月に 1 回だけフルバックアップを行い、それ以外の日には差分バックアップか、レベル 1〜9 のバックアップを行います。

フルバックアップから次のフルバックアップまでの期間は「バックアップサイクル」と呼ばれます。図 3-2 は、1 週間のバックアップサイクルを示しています。この例では、毎日曜日にクライアントのフルバックアップを行い、その他の曜日には差分バックアップを行なっています。

図 3-2 バックアップサイクルが 1 週間の場合

Graphic

バックアップスケジュールを使って、Backup サーバーの負荷を調整し、分散させることができます。ネットワークの大きさによっては、すべてのクライアントに同じスケジュールを適用できます。たとえば、すべての社員が休んでいる休日にフルバックアップを行う場合は、すべてのクライアントにデフォルトのスケジュールを適用できます。デフォルトのスケジュールでは、日曜日にフルバックアップを行い、それ以外の曜日には差分バックアップを行います。図 3-3 は、クライアント A、クライアント B、およびクライアント C の 3 つのクライアントでの、デフォルトのスケジュールの例を示しています。

図 3-3 複数のクライアントで Backup のデフォルトのスケジュールを使用する場合

Graphic

フルバックアップに長時間かかる場合には、バックアップを分散させることができます。たとえば、クライアント A のフルバックアップを日曜日に行うスケジュール、クライアント B のフルバックアップを火曜日に行うスケジュール、そしてクライアント C のフルバックアップを木曜日に行うスケジュールを設定します。図 3-4は、複数のクライアントでバックアップスケジュールを分散させる方法を示しています。

図 3-4 複数のクライアントのスケジュールを 1 週間に分散させる場合

Graphic

Backup サーバーの負荷を調整し、分散させると、サーバーの効率が向上します。また、クライアントのグループごとに異なる開始時刻を指定することも、サーバーの効率向上に役立ちます。

バックアップスケジュール

Backup では、独自のバックアップスケジュールを簡単に設定できます。ただし、自分の環境に最も適したバックアップスケジュールを決めるためには、慎重に画を立てる必要があります。

バックアップスケジュールを作成するときには、次の事柄を検討します。

さらに、ファイルの復旧に関するポリシーを決定する必要があります。たとえば、ユーザーが、少なくとも 3 か月の間に失われたファイルを復旧する場合 (3 か月の保持ポリシー) には、メディアデータベースの中にすべてのセーブセットを 3 か月間保存する必要があります。一方、過去 1 か月のデータを復旧するだけでよいのであれば、レベル 1〜9 バックアップを使って、保存しなければならないボリュームの量を減らすことができます。

Backup が復旧に使用するデータが保存されている期間は、各クライアントに関連付けられているブラウズポリシーと保持ポリシーによって決まります。Backup がデータライフサイクルをどのように管理するかについては、「ブラウズポリシーと保持ポリシーによるデータライフサイクルの管理方法」を参照してください。

例 : 大規模なクライアントファイルシステムのスケジュール

400 KB/秒という平均的なバックアップ速度では、10G バイトのデータを持つクライアントのフルバックアップには、終了までに約 5.5 時間必要となります。このようにバックアップに要する時間が長いクライアントセーブセットでは、毎回フルバックアップを行うスケジュールは不適当です。

この場合には、クライアントのディスクボリュームを複数のバックアップグループに分割し、それぞれ別のタイミングでバックアップするようにスケジュールを立てます。1 台のクライアントのセーブセットを複数のバックアップグループに分割すると、クライアントのすべてのファイルが何回かに分けてバックアップされることになります。これはすべてのローカルデータを一回でフルバックアップするよりも時間の節約になります。

クライアントのファイルシステムを個別にバックアップするには、「Clients」リソースに個々のファイルシステムをアドレス指定して、同じクライアントのエントリの追加と構成を繰り返します。たとえば、ファイルシステム /usr のバックアップについては、あるグループのバックアップスケジュールを使って第 1 のクライアントリソースを構成します。さらに、別のファイルシステム /var のバックアップスケジュールについては、別のグループで別のバックアップスケジュールを使って第 2 のクライアントリソースを構成します。

注意 - 注意 -

複数のバックアップスケジュールを作成し、セーブセットを明示的に指定すると、その指定リストに含まれていないファイルやファイルシステムはバックアップから除外されます。これには、システムに新たに追加されたディスクボリュームも含まれます。「Save Set」属性に特別な値「All」を指定すれば、このような危険は生じません。Backup は新しいディスクボリュームを自動的にバックアップに追加します。

スケジュール構成属性

カスタマイズしたバックアップスケジュールを作成するには、「Schedule」リソースで次のスケジュール構成値を定義する必要があります。

バックアップスケジュールの構成の順序

独自にカスタマイズしたスケジュールを使用する場合には、スケジュールを構成したあとに、「Clients」リソースの中のクライアントまたはセーブセットと関連付ける必要があります。毎日自動的に行われるスケジュールされたバックアップの開始時刻は、クライアントセーブセットが関連付けられているバックアップグループによって決まります。データがブラウズまたは復旧に使用できる期間は、スケジュールではなく、クライアントのセーブセットに対して構成されているブラウズポリシーと保持ポリシーによって決まります。

バックアップレベル

フルバックアップを毎日行うのは現実的または効率的でない場合があるので、Backup では、その自動的に実行されるスケジュールされたグループバックアップの際のバックアップ操作のレベルを指定できるようになっています。フルバックアップが行われる回数を制限することで、サーバーの効率を損なわずに、データを保護できます。各種のバックアップレベルを使って、バックアップの完了に必要なボリュームの数および時間と、ディスククラッシュからの復旧に必要なボリュームの数および時間を調整できます。

Backup は、ファイルシステムデータに関して、次の 4 種類のバックアップレベルをサポートしています。

Backup によるバックアップレベルの使用方法

バックアップスケジュールによって、バックアップサイクル中の指定した日に、どのレベルのバックアップが行われるかを定義します。これらのバックアップレベルを 1 つ以上組み合わせて、バックアップスケジュールをカスタマイズできます。カスタマイズしたスケジュールの中でバックアップレベルの使用を検討している場合には、次のことに注意して、自分の環境に合ったスケジュールを作ってください。

注意 - 注意 -

オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースは、Backup サーバーがバックアップされるたびにバックアップされます。一般に、これはサーバーのバックアップレベルに準拠します。たとえば、Backup サーバーのバックアップレベルが「フル」ならば、オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースもフルバックアップが行われます。Backup サーバーのバックアップが「レベル 5」ならば、オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースのバックアップもレベル 5 です。ただし、サーバーのバックアップレベルが「差分」ならば、オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースのバックアップはレベル 9 です。

バックアップレベルによる動作

バックアップレベルはクライアントのバックアップスケジュールと関連しています。バックアップレベルの定義は、ディスククラッシュからの復旧に要する時間や、必要となるバックアップボリュームの数などに直接に影響します。

これ以降の説明では、バックアップレベルの動作と、データの損失時の復旧に必要となるデータの量を、図示しています。

10 月 2 日にフルバックアップが行われます。10 月 3 日には、フルバックアップ以降に変更されたすべてのデータが差分バックアップによって保存されます。10 月 4 日には、10 月 3 日以降に変更されたすべてのデータが差分バックアップによって保存されます。10 月 5 日には、レベル 7 バックアップによって、フルバックアップ以降に変更されたすべてのデータが保存されます。10 月 5 日にディスククラッシュから完全に復旧するためには、フルバックアップのボリュームとレベル 7 のボリュームの 2 つのボリュームだけが必要です。10 月 3 日と 4 日のボリュームに入っているデータは、レベル 7 バックアップに含まれているので、これらのボリュームは不要です (図 3-5 を参照)。

図 3-5 例 : 10 月 2 日から 10 月 8 日までのバックアップ

Graphic

10 月 6、7、および 8 日は、レベル 7 バックアップ以降に変更されたすべてのデータが差分バックアップによって保存されます。10 月 9 日には、図 3-6 に示すように、レベル 5 バックアップによって、フルバックアップ以降に変更されたすべてのデータが保存されます。10 月 9 日にディスククラッシュから完全に復旧するためには、フルバックアップのボリュームとレベル 5 のボリュームの 2 つのボリュームだけが必要です。レベル 7 バックアップのボリュームと、それ以降の差分バックアップのボリュームに入っているデータは、レベル 5 のボリュームに含まれているので、これらのボリュームは不要です。

図 3-6 例 : 10 月 2 日から 10 月 15 日までのバックアップ

Graphic

10 月 12 日に、レベル 7 バックアップによって、これよりも若い番号の直前のバックアップ以降に変更されたすべてのデータがバックアップされます。この例では 10 月 9 日のレベル 5 バックアップがこれに該当します。10 月 12 日にディスククラッシュから復旧するためには、フルバックアップのボリューム、レベル 5 のボリューム、および新しいレベル 7 のボリュームの 3 つのボリュームが必要となります (図 3-6 を参照)。

10 月 16 日に、レベル 5 バックアップによって、これよりも若い番号の直前のバックアップ以降に変更されたすべてのデータがバックアップされます。これよりも若い番号 (レベル 1 〜 4) のバックアップは行われていないので、レベル 5 バックアップによって、フルバックアップ以降に変更されたすべてのデータがバックアップされます。10 月 16 日にディスククラッシュから復旧するためには、フルバックアップのボリュームと新しいレベル 5 のボリュームの 2 つのボリュームが必要となります (図 3-7 を参照)。

図 3-7 例 : 10 月 2 日から 10 月 16 日までのバックアップ

Graphic

レベル 1-9 バックアップを使うことで、使用しなければならないボリュームの数を制御できます。バックアップ方法を慎重に計画することで、ボリュームの数を最小限に抑えながら、すべてのデータをディスクに復旧することが可能になります。ディスククラッシュからの復旧に必要なボリュームの数が少ないほど、ディスクの復旧に費やされる時間も削減できます。

また、バックアップのデータを圧縮し、不要なデータを削除するディレクティブを使うことで、データのバックアップに要する容量と時間を制御できます。たとえば、バックアップの実行時に、特定のファイルまたはファイルシステムを省略するよう Backup に指示できます。ディレクティブの詳細は、「ディレクティブとは」を参照してください。

インデックス管理

Backup では、バックアップしたファイルは、クライアントファイルインデックスとメディアデータベースに記録されます。クライアントファイルインデックスによって、セーブセットに属しているファイルが追跡され、メディアデータベースによって、ボリュームの名前、ボリューム上のセーブセットのバックアップの日付、および各セーブセット内のファイルシステムが追跡されます。Backup では、設定したブラウズポリシーと保持ポリシーに従って、クライアントファイルインデックスとメディアデータベースの大きさを自動的に制御できます。ブラウズポリシーと保持ポリシーの詳細は、「ブラウズポリシーと保持ポリシーによるデータライフサイクルの管理方法」を参照してください。

インデックスの大きさと構造

クライアントファイルインデックスの構造は、ファイルサイズに関するオペレーティングシステムの制約を受けずに、クライアント一台に対応するクライアントファイルインデックスは増大し続けることができるように構築されています。クライアントファイルインデックスの増大に伴って、2G バイトのセグメントへと分割されます。クライアントのファイルインデックスの大きさをチェックするには、次の例のように nsrls -f コマンドを使用します。


# nsrls -f /nsr/index/clientname/db

この例に示すパスは、デフォルトパスです。インデックスが置かれるパスを変更するには、「Clients」リソースの「Details」ビューで「Index Path」属性の値を変更します。

クライアントのファイルインデックスの大きさのチェックに UNIX の ls コマンドは使用できません。nsrls -f コマンドの出力は、次のような形式です。


# nsrls -f /nsr/index/mars/db
Volume id 0: /nsr/index/mars/db
 Fid |    Kbytes |     Count | Name
------------------------------------------
   0 |     18504 |    119798 | sr
   1 |      2016 |    119798 | sr_i0
   2 |      1768 |    119436 | sr_i1

クライアントファイルインデックスとメディアデータベースを手動で縮小するには

クライアントファイルインデックスとメディアデータベースの大きさを手動で制御することもできます。

ボリュームがパージまたは削除されても、クライアントファイルインデックスが自動的に縮小されるわけではありません。インデックスにできた隙間は、あとで追加されるレコードに割り当てられます。インデックスのエントリをパージまたは削除した直後にクライアントファイルインデックスの大きさを小さくするには、次のコマンドを実行します。


# nsrck -C clientname

すべてのクライアントのインデックス領域を解放するには、 /nsr/index ディレクトリに移って、 nsrck -C コマンドを実行します。

インデックスが大きいと、nsrck コマンドを使った圧縮に数時間かかることがあります。詳細は、nsrck、mminfo、scanner、nsr、および nsrmm のマニュアルページを参照してください。

保持ポリシーを無効にするには

セーブセットは、その期限が切れるまで、ボリュームとメディアデータベースに保持されています。通常、セーブセットは、セーブセットそのものと、復旧のためにそのセーブセットに依存しているすべてのセーブセットが保持ポリシーに適合する場合に、期限が切れた時点で再利用可能になります。ただし、セーブセットに対して有効期限を明確に指定して、保持ポリシーを無効にすることもできます。この場合でも依存関係の規則は適用されるので、セーブセットが再利用可能としてマークされるためには、そのセーブセットに依存しているすべてのセーブセットが「再利用可能」としてマークされる必要があります。

保持ポリシーを明示的に無効にするには、手動バックアップコマンドの save -e を入力します。


# save -e

バックアップのパフォーマンス

バックアップのパフォーマンスは、Backup の設定内容とともに、Backup が運用されているネットワーク環境に大きく左右されます。パフォーマンスの算出には、CPU の速度、データストレージデバイスの速度、ネットワーク上の制約、およびネットワークトラフィックの量など、Backup の外部の要因をいくつか考慮する必要があります。

Backup 内部では、次の 2 つの属性を変更することで、パフォーマンスを調整できます。

ストレージデバイス上にあるデータを多重化する (複数のデータに分割する) ように設定することによって、バックアップの速度を改善できます。これにより、複数のセーブセットのデータを 1 つのストレージボリュームに書き込むことや、1 つのセーブセットのデータを複数のボリュームに分散させることができます。多重化されるセーブセットは、定義上、ストレージボリュームの同じプールに属していなければなりません。この多重化によって、複数のクライアントからのデータの流れを最適化し、Backup で使用できるすべてのストレージデバイスに分散します。

復旧時に、1 つのセーブセットのデータが複数のボリュームに書き込まれるためにパフォーマンスが低下することがあります。

Backup では、セーブセット識別番号 (ssid) を使ってデータにコードを付けて追跡することによって、各セーブセットのデータの整合性を保っています。特定のストレージデバイス上で可能な多重化の程度は、そのデバイスの「Target Sessions」の値を使って定義します。

一般に Backup では、複数のセーブセットをそれぞれ別々のデバイスに書き込むよりも、同じボリュームに対して多重化する方が高い効率を実現できます。このため、各デバイスに、そのデバイスの「Target Sessions」の数だけセーブセットを割り当て、この数を超えると次のデバイスにセーブセットを割り当てるようにしています。

イベント通知

Backup では、いくつかのプログラムとインターフェースによって、システム管理者に動作と状態を報告します。このために、「通知」という手段を使って、どのイベントを報告するか、これらのイベントをどのように報告するかといった事柄を指定します。

事前構成済み通知

Backup にはあらかじめ構成されている多くの通知があり、これらを使って特定の Backup イベントに対する Backup の応答を定義します。事前構成済み通知に関しては、「「Notifications」リソース」で説明しています。事前構成済み通知を編集して、カスタマイズした通知を作成できます。nwadmin プログラムの GUI で 「View」メニューの「Details」を選択するか、nsradmin インタフェースで「Options」メニューの「Display Options」を選択してから「Hidden」を選択します。

定型的データ移動操作の報告

スケジュールされたグループバックアップ、グループクローン生成、およびアーカイブの各操作がどの程度完了したかについては、savegrp プログラムによってセーブグループ完了レポートとして管理者に報告されます。このレポートは、「Savegroup Completion」という名前の事前構成済み通知によって作成されます。レポートはスーパーユーザーに電子メールで送信され、ログファイル /nsr/logs/messages に記録されます。このレポートには次の情報が含まれています。

このレポートは Backup サーバーの指定のデフォルトプリンタに送られて、ブートストラップ情報がハードコピーとして出力されます。この出力は、安全な場所に保管しておく必要があります (この印刷レポートは、Bootstrap という名前の事前構成済み通知によって作成される)。最新の印刷レポートに記載されたブートストラップ情報が参照できれば、障害復旧作業は大幅に軽減されます。

Backup には、Backup クライアントファイルインデックスの内容を照会するための nsrinfo プログラムが用意されています。よく使われる nsrinfo コマンドとそのオプションについての説明は、付録 B 「コマンド行リファレンス」にあります。

また、発生している Backup 動作を監視するためのキャラクタベースインタフェースの nsrwatch プログラムも用意されています。

ストレージ管理アプリケーションレポート

表 3-1 に、Backup に用意されている、ストレージ管理システムの内容を照会するためのプログラムを示します。よく使われるコマンドとそのオプションについての説明は、付録 B 「コマンド行リファレンス」にあります。

表 3-1 ストレージ管理レポートプログラム

プログラム名 

機能 

mminfo

ストレージボリュームの内容とモード、および格納されているセーブセットの識別番号と状態に関するレポートを生成する 

mmlocate

ストレージボリュームのユーザー定義の位置を示すレポートを生成する 

nsrinfo

クライアントファイルインデックスの内容を示すレポートを生成する 

nsrmm

Backup が認識しているストレージデバイスの状態を示すレポートを生成する 

Backup サーバーの統計情報および診断情報レポート

Backup の診断情報を報告するメッセージは Backup 管理者インターフェースに表示され、Backup メッセージファイル /nsr/logs/messages にも記録されます。これらのメッセージには、警告およびエラーの条件と、接続の切断に関する通知が含まれています。

メッセージログファイル

Backup サーバーデーモン (nsrd、nsrindexd、nsrmmdbd、nsrmmd) によって生成されるメッセージは、Backup の messages ログと、通常は /nsr/logs ディレクトリにある daemon.log ファイルに記録されます。

保守作業

この節では、Backup サーバーのインストールと構成を行なったあとに必要な作業について説明します。

メッセージログの管理

Backup では、Backup サーバーデーモンによって生成されたメッセージは、/nsr/logs ディレクトリの中のメッセージログファイルに格納されます。ログファイルのサイズが大きくなりすぎたら、ログからメッセージを削除しなければなりません。ログのサイズを自動的に制御するには、/etc ディレクトリにある Backup 起動スクリプト内の変数を使用するか、オペレーティングシステムサービスを使用するスクリプトを作成します。

起動スクリプトでログファイルを削除する方法

Backup サービスによって Backup ログファイルを管理する方法を変更するには、nsrd デーモンを起動する前に、/etc/init.d ディレクトリにある Backup 起動スクリプトの networker 中の環境変数を次のように変更します。

nsrd デーモンは、起動されるたびに daemon.log ファイルのサイズをチェックします。デフォルトでは、daemon.log ファイルが上限サイズの 1024 K バイトに達した時点でファイル名が daemon.001 に変更され、新たに空の daemon.log が作成されます。daemon.log ファイルの空き領域がなくなると、すでに存在するファイル名が順番にずれていきます。つまり、daemon.001 の名前が daemon.002 に変更され、daemon.log の名前が daemon.001 に変更され、新たに空の daemon.log ファイルが作成されます。このプロセスは NSR_MAXLOGVERS の値に達するまで繰り返され、その時点で、最も番号の大きいログが削除されます。

注意 - 注意 -

この削除メカニズムは nsrd デーモンの起動時にのみ機能します。nsrd デーモンは、ログファイルが NSR_MAXLOGSIZE の上限を超えたかどうかを定期的にチェックすることはしません。nsrd が長時間にわたって実行されていると、ログファイルのサイズが極端に大きくなる可能性があります。削除メカニズムを有効にするには、nsr_shutdown を実行して Backup デーモンを停止したあとに、nsrd デーモンと nsrexecd デーモンを再起動します。

オペレーティングシステムサービスを使ってログファイルを削除するには

オペレーティングシステムサービスを使って、Backup ログファイルのサイズを自動的に管理できます。

Solaris ソフトウェアには、syslog メッセージファイル (/var/log/syslog) を管理するために、2 つの要素で構成されるメカニズムが用意されています。この 2 つの要素とは、シェルスクリプト (/usr/lib/newsyslog) と、このスクリプトを定期的に呼び出すためのスーパーユーザー用の crontab エントリです。

newsyslog スクリプトを変更して、Backup サーバーのログファイルを管理し、保持できます。次に示すようにスクリプトを変更すると、Backup サーバーの daemon.log ファイルが過去 3 ファイルにわたって保持されます。

Backup ログファイルを管理するには、次の操作を行います。

  1. 適当なテキストエディタを使って、/usr/lib/newsyslog に以下の行を追加します。


    LOGDIR=/nsr/logs
LOG=daemon.log
if test -d $LOGDIR
then
    cd $LOGDIR
    test -f $LOG.1 && mv $LOG.1 $LOG.2
    test -f $LOG.0 && mv $LOG.0 $LOG.1
    test -f $LOG   && mv $LOG   $LOG.0
    cp /dev/null $LOG
    chmod 644 $LOG
fi

    Backup デーモンを終了させ、再起動させるまで、新しいログファイルは使用できません。nsr_shutdown コマンドを直接入力するか、あるいは newsyslog スクリプトにこのコマンドを追加して、デーモンを終了します。スケジュールされた保存操作の過程でこのスクリプトが実行されることがないように注意します。その後、次のコマンドを使って Backup を手動で再起動します。


    # /etc/init.d/networker start

  2. newsyslog スクリプトを実行する頻度を制御するためのエントリをスーパーユーザー用の crontab に追加します。

    次の例に示すエントリは、newsyslog スクリプトを毎日曜日の 4:05 a.m. に起動します。


    5 4 * * 6   /usr/lib/newsyslog

    Solaris システムに newsyslog スクリプトとそれを呼び出す crontab エントリがない場合は、newsyslog スクリプトを手動で作成し、これに crontab エントリを追加します。詳細は、crontab(1) のマニュアルページを参照してください。

Backup サーバーライセンスを別のマシンに移すには

Backup サーバーライセンスを別のマシンに移すには、次の操作を行います。

  1. Backup を使って、古い Backup サーバー上のすべてのファイルシステムに対してフルバックアップを行います。

  2. 古いサーバー上の Backup デーモンを、nsr_shutdown -a コマンドを使って終了します。

  3. 古いサーバーの /nsr ディレクトリ全体を tar テープに落とし、これを新しいサーバーに取り込みます。

    /nsr が古いサーバーでシンボリックリンクになっている場合は、新しいサーバーでも /nsr をシンボリックリンクとして設定します。

  4. 古いサーバーを停止し、すべてのデバイスを取りはずします。

  5. 新しいマシンを停止し、新しいサーバーにハードウェアデバイスを取り付け、両方のマシンを再起動します。先に古いマシンを起動してから、新しいマシンを起動します。

  6. 新しいサーバーに Backup ソフトウェアをインストールします。

    オートチェンジャがある場合は、Backup デーモンを起動するオプションは選択しないようにします。Backup デバイスドライバのインストールとテスト方法については、『Solstice Backup 5.1 ご使用にあたって』を参照してください。

    新たにホストを作成したので、Backup デーモンを起動する前に、この新しいホストのインデックスエントリを正しく定義する必要があります。インデックスエントリを修正するには、次の 2 つの方法があります。

    • クライアントリソースを変更する前に、オペレーティングシステムレベルで、新しいサーバーに古いサーバーと同じホスト名を付けます。

    • 古いサーバーと同じ設定値を使って、新しいサーバーに新しいホスト名を付けます。

    新しいサーバーに新しいホスト名を付けるには、次の操作を行います。

  1. 古いサーバーと同じ設定値で、新しいサーバーに新しいホスト名を付けます。

  2. 古いサーバーのホスト名のエントリを削除します。

  3. 古いサーバーと新しいサーバーで、Backup デーモンを終了します。


    # nsr_shutdown -a

  4. 古いサーバーのインデックスエントリがあるディレクトリに移ります。


    # cd /nsr/index

    新しいサーバーホスト名のエントリは空になっています。

  5. 新しいサーバーホスト名のエントリを削除します。次に例を示します。


    # rmdir new-hostname

    このエントリを削除しておかないと、次の手順で、新しいサーバー用の正しいエントリではなく、別のエントリが作成されてしまいます。

  6. 古いインデックスディレクトリ名を、新しいサーバーホスト名に変更します。


    # mv old-hostname new-hostname

    Backup デーモンが新しいサーバーで起動します。


    new-server syslog: Backup Server: (notice) started
new-server syslog: Backup Registration: (notice) invalid auth codes
detected.
new-server syslog:
new-server syslog: The auth codes for the following licenses enablers
are now invalid.
new-server syslog: The cause may be that you moved the Backup server
to a new computer.
new-server syslog: You must re-register these enablers within 15 days
to obtain new codes.
new-server syslog:
new-server syslog: License enabler #xxxxxx-xxxxxx-xxxxxx (Backup
Advanced/10)

    新しい Backup サーバーを再登録します。Backup を別のシステムに移してから 15 日以内に、新しいサーバーを Sun に登録する必要があります。

    新しいサーバーを再登録する方法については、「ソフトウェアを登録し認証を受けるには」を参照してください。

    サーバーを移したら、次の操作を行います。

    1. スケジュールされたバックアップにすべてのクライアントが含まれていることを確認します。

    2. Backup の recover プログラムを使って、すべてのクライアントインデックスが表示され、復旧可能な状態であることを確認します。

    3. できる限り早いうちに、新しいサーバーのインデックスをバックアップするか、新しいサーバーのフルバックアップを行います。

    古いサーバーをクライアントとして設定したい場合は、古いサーバーからすべての Backup ソフトウェアと /nsr ディレクトリを削除してから、Backup クライアントソフトウェアをインストールし直します。