test

Solstice Backup 5.1 管理者ガイド

付録 C 障害追跡

Backup で問題が起こった場合や製品が予想どおりに動作しない場合は、この付録を利用して問題を診断します。ここで扱う内容は、次のとおりです。

ご購入先に連絡する前に揃えておく情報

この付録の説明では問題を解決できない場合は、ご購入先に連絡する前に、次の情報を揃えておいてください。

次の情報も必要です。

Backup によるバックアップと復旧

この節では、Backup によるバックアップと復旧の操作の際に起こり得るさまざまな問題の障害追跡方法を説明します。

Backup デーモンの検査

Backup が正常に起動できない場合は、デーモンが正常に動作していない可能性があります。必要なデーモンが動作しているかどうかを判断するには、シェルプロンプトで次のコマンドを入力します。


# ps -aux | grep nsr

あるいは、次のコマンドを入力します。


# ps -ef | grep nsr

システムから、次のような出力結果が得られます。


12217 ?        S  0:09 /usr/sbin/nsrexecd -s jupiter
12221 ?        S  2:23 /usr/sbin/nsrd
12230 ?        S  0:00 /usr/sbin/nsrmmdbd
12231 ?        S  0:01 /usr/sbin/nsrindexd
12232 ?        S  0:00 /usr/sbin/nsrmmd -n 1
12234 ?        S  0:00 /usr/sbin/nsrmmd -n 2
12235 ?        S  0:00 /usr/sbin/nsrmmd -n 3
12236 ?        S  0:00 /usr/sbin/nsrmmd -n 4
12410 pts/8    S  0:00 grep nsr

この出力からデーモンが動作していないということが判明した場合は、次のように入力して Backup デーモンを起動させます。


# /etc/init.d/networker start

クライアントのバックアップが停止しない

バックアップ中にプロセスを停止するには、「Group Control」ウィンドウの「Stop」ボタンをクリックします。これで、選択状態にあるグループの全クライアントのバックアッププロセスが停止するはずですが、クライアントが停止しないこともあります。この場合、サーバーがなお動作中であることを示すメッセージが表示されます。

クライアントマシン上でこの問題を解決するには、次のコマンドを使って、save プロセスを実行中のクライアントを特定します。


# ps -aux | grep save

あるいは、次のコマンドを使用します。


# ps -ef | grep save

このコマンドによって、save に関連する各プロセスのプロセス識別番号 (pid) がわかります。次のコマンドを使って、pid ごとに save プロセスを停止させます。


# kill -9 pid

クライアントのファイルインデックスが大きくなり過ぎても通知されない

クライアントのファイルインデックスのサイズが大きくなり過ぎた場合でも、Backup はユーザーには通知しません。したがって、ユーザーが定期的にシステムを監視して、クライアントのファイルインデックスのサイズを調べる必要があります。Backup クライアントファイルインデックスを管理する方法は、「インデックス管理」を参照してください。

「Auto Media Verify」が有効なときにメディア位置エラーが発生した

プールに対して「Auto Media Verify」機能を有効にしておくと、そのプール内のボリュームに書き込まれているデータが、保存時に Backup によって検査されます。この検査では、メディアに書き込まているデータの記録を読み取り、それを元の記録と比較します。ボリュームが書き込み中にいっぱいになった場合、あるいはデータを保存するのにボリュームが不要になった場合は、そのボリュームへの書き込みが終わったあとでメディアが検査されます。

メディアを検査するには、すでに書き込まれているデータを読み取るために、nsrmmd デーモンによってボリュームの位置を決めなければなりません。これは、常に 1 回でできるとは限りません。失敗した場合は、Backup 管理プログラム nwadmin で次の警告メッセージが表示されます。


media warning: /dev/rmt2.1 moving: fsr 15: I/O error
media emergency: could not position jupiter.007 to file 44, record
16

このメッセージに対しては、ユーザーは何も操作する必要はありません。Backup によって、正しい位置が探されます。正しい位置が見つかってメディアの検査が完了すると、検査が完了したことを示す次のメッセージが表示されます。


media info: verification of volume "jupiter.007" volid 30052
succeeded.

この場合、前に表示されたメッセージは、Backup がメディア上で正しい位置を見つけ出せないことを示すだけなので、無視してください。問題が重大であればメディア検査は失敗し、そのあとのメッセージで失敗の原因が示されます。

「PACKET RECEIVE BUFFER」が表示されて NO ECB カウンタが増加する

サーバーがテープがマウントされるのを待機しているとき、あるいはオートチェンジャのボリュームが変更されているときには、NetWare クライアント上に「PACKET RECEIVE BUFFER」のメッセージが表示され、NO ECB カウンタが増加します。

この問題を解決するには、nsr_shutdown コマンドを使って Backup サーバーを停止させます。そのあと、次のように手動で Backup を再起動させます。手動によるコマンドの再起動については、「Backup デーモンの検査」を参照してください。

Backup が、Solaris クライアント上の所定の場所に見つからない

Solaris の場合は、Backup の実行可能ファイルはデフォルトで /usr/sbin/nsr にインストールされています。ルートディレクトリに至る検索パスに /usr/sbin/nsr を持っていない Backup サーバー上でグループバックアップを起動すると、自分の Backup の実行可能ファイルを /usr/sbin/nsr に持っているクライアント上でのバックアップは失敗します。これは、/usr/sbin/nsr コマンドが検索パス内にないからです。

最善の解決法として、この問題を起こしたクライアントで、隠し属性の「Executable Path」を設定します。この属性を設定するには、詳細情報ビューで「Clients」属性を表示させ、「Executable Path」属性に実行可能ファイルへのパス /usr/sbin/nsr を入力します。

もう 1 つの解決法として、Backup サーバー上でルートディレクトリに至る検索パスを修正して、ローカルに /usr/sbin/nsr を持っていない場合であっても、これをパスに含めるようにします。

scanner プログラムでボリュームに読み取り専用のマークが付けられる

scanner プログラムを使ってバックアップボリュームのインデックスを作成し直すと、scanner プログラムによって、ボリュームに読み取り専用のマークが付けられます。

これは、バックアップボリュームの最新のセーブセットが上書きされるのを防ぐための保護手段です。メディアを読み取り専用にしないでデータを書き込むには、次のように nsrmm -o コマンドを使います。


# nsrmm -o notreadonly volume-name

別のディレクトリへのインデックス復旧が失敗する

前にインデックスが置かれていたディレクトリ以外のディレクトリにインデックスを復旧しようとすると、次のエラーメッセージが表示されます。


WARNING: The on-line index for `client-name' was NOT fully recovered.
There may have been a media error. You can retry the recover, or
attempt to recover another version of the `client-name' index.

インデックスは、元のディレクトリ以外のディレクトリには復旧しないでください。いったん元のディレクトリに復旧させてから、別のディレクトリに移します。

インデックスは隙間だらけのファイルなので、単に UNIX の cp コマンドを使うと、元のファイルよりも広いディスクスペースを使うファイルができます。インデックスを移動させるには、スーパーユーザーになって、/nsr/index ディレクトリ内から次のコマンドを実行します。


# uasm -s -i client-index-directory-name | (cd target-directory; uasm -r)

クライアントの別名に関する問題の原因

次に示すいずれかの状況が発生したら、クライアントの別名に関する問題が原因になっていると考えられます。

次に示すマシンとサイトでは、クライアントの別名を変更する必要があります。

注意 - 注意 -

ほかのホストによって共有されている別名は、この行に指定しないでください。

構成で使用できない文字

Backup の旧バージョンからアップグレードする場合は、ラベルテンプレート、ディレクティブ、グループ、ポリシー、スケジュールの構成名には、次に示す特殊文字は使用できなくなりました。

/¥¥*?[]()$!^;'¥"`‾><&|{}

このように変更されたのは、ボリュームラベル、ディレクティブ、グループ、ポリシー、スケジュールが、コマンド行オプションとしてさまざまな Backup プログラムに渡されることが多いためです。

現在の構成名にこれらの特殊文字を使っている場合は、Backup のインストール時に、それらを最初に作成したリソース内で下線 (_) に置き換えられます。

ただし、これらの構成が適用される「Clients」リソースでは、選択された構成は、Backup によって自動的にその前の「Default」構成に置き換えられます。

構成名を変更した場合は、その構成を選択し直して、個々のクライアントにもう一度適用しなければなりません。

scanner プログラムがレコードサイズの入力を要求する

-s オプションを指定し、-i オプションまたは -m オプションを指定しないで scanner プログラムを実行すると、次のメッセージが表示されます。


please enter record size for this volume ('q' to quit) [xx]

角括弧内の数字 [xx] は、前回の照会で指定されたレコードサイズです。

scanner コマンドは常にテープを巻き戻してボリュームラベルを読み取り、ブロックサイズを判断します。ボリュームラベルが壊れていたり、読み取れなかったりした場合は、ブロックサイズを K バイトで入力するよう要求するメッセージが表示されます。

32 以上の整数でブロックサイズを入力します。32 未満の整数を入力すると、次のメッセージが表示されます。


illegal record size (must be an integer >=32)

新規インストール直後に復旧が失敗する

システムに初めて Backup をインストールした直後に nwrecover プログラムを起動しようとすると、「nwrecover: Program not found.」のエラーメッセージが表示されます。

ディスクスペースを節約するために、Backup では、はじめてのバックアップが完了してからクライアントインデックスを作成します。クライアントインデックスにブラウズのためのエントリがないと、nwrecover プログラムはデータを復旧できません。この問題を避けるために、クライアント上で Backup によるバックアップを選択します。

バックアップが中断された場合のファイルの復旧

Backup デーモンを終了させてバックアップを停止させると、デーモンの終了時にはメディアデータベースが更新されないので、ファイルを復旧することはできません。したがって、要求されたファイルがどのボリュームにあるかは、Backup にはわかりません。

新しいクライアントをバックアップすると、デフォルトのフルバックアップになる

新しいクライアントをはじめてバックアップすると、次のメッセージが表示されます。


mars:/usr no cycles round in media db; doing full save.

この例では、クライアント mars 上のファイルシステム /usr は、メディアデータベースにフルセーブがリストされていません。したがって、そのクライアントのスケジュール用に選択されているバックアップのレベルに関わらず、Backup は必ずフルバックアップを実行します。そのクライアントを障害から復旧するためには、この機能は重要です。

上記のメッセージは、サーバーの時計とクライアントの時計が合っていないときにも、表示されます。これを防ぐには、必ず Backup のサーバーとクライアントの時間帯を同じにして、両方の時計を合わせておく必要があります。

名前変更したクライアントが古いバックアップを復旧できない

Backup は、自分がバックアップするすべてのクライアントのクライアントファイルインデックスを保守しています。クライアントの名前を変更すると、そのクライアントのインデックスは新しいクライアント名と関連付けられず、古いクライアント名でバックアップされているファイルの復旧ができなくなります。新たに名前変更したクライアントで古いバックアップデータを復旧する場合は、「古いバックアップデータを新しいクライアント名で復旧するには」を参照してください。.

古いバックアップデータを新しいクライアント名で復旧するには

  1. 古いクライアント名で構成されている「Client」リソースを削除します。

  2. 新しいクライアント名の「Client」リソースを新しく作成します。

  3. 次のようにして、Backup デーモンを停止させます。


    # nsr_shutdown

  4. 新しいクライアント用に自動的に作成されたインデックスディレクトリを削除します。

    ただし、単に古いクライアントのインデックスディレクトリに新しいクライアントインデックスをコピーしても、新しいクライアントインデックスが古いクライアントのインデックスディレクトリの内部にネストされるだけです。

  5. 次のように mv コマンドを使って、古いクライアントのファイルインデックスのディレクトリ名を変更します。


    # mv /nsr/index/old-client /nsr/index/new-client

ディスクラベルのエラー

エラーメッセージ「No disk label」が表示されたら、誤って光デバイス以外のデバイスが光デバイスとして構成されている可能性があります。「Devices」リソースの「Media Type」属性が、使いたいデバイスのメディアと合っていることを確認し、必要な場合は修正します。

HP テープドライブでサポートされていないメディアによるエラー

Hewlett-Packard 社のテープドライブの一部の機種では、たとえば 60 m といった特定の長さの 4 mm テープだけが読み取り可能で、90 m テープ、120 m テープは読み取れません。使用している HP 製のドライブで読み取れるテープのタイプを確認するには、ドライブに添付されているハードウェアマニュアルを参照してください。

HP 製のテープドライブでサポートされていないテープを読み取ろうとすると、次のエラーメッセージが表示されます。


nsrmm: error, label write, No more processes (5)
 

scanner: error, tape label read, No more processes (11)
scanning for valid records ...
read: 0 bytes
read: 0 bytes
read: 0 bytes

ブートストラップ情報を印刷できない

サーバーのブートストラップが印刷されない場合は、使用しているプリンタ名を「Groups」リソースの隠し属性として入力しなければならないことがあります。隠し属性を使うには、GUI を使用する管理プログラム nwadmin の場合は、「View」メニューの「Details」を選択します。カーソルを使用する管理プログラム nsradmin の場合は、「Options」メニューの「Hidden」を選択します。

ブートストラップを印刷するプリンタ名を、「Groups｝リソースの「Printer」属性に入力します。

サーバーインデックスの保存

Backup サーバーが属しているグループが有効でなくても、あるいは Backup サーバーがどのグループにも属していなくても、Backup によって自動的にサーバーのブートストラップ情報がバックアップ対象の各グループとともに保存されます。ただしそのような場合は、セーブグループ完了レポートに次のメッセージが表示されます。


jupiter: index Saving server index because server is not in an
active group

これは、システム障害の際に復旧プロセスが長くなるのを防ぐためのものです。サーバーの「Client」リソースをできるだけ早く構成して、有効になっているバックアップグループに加えます。

著作権侵害

Backup を複数のサーバーにインストールして、同じ Backup イネーブラコードを使うと、セーブグループ完了メールに、次のようなメッセージが表示されます。


--- Unsuccessful Save Sets ---
* mars:/var save: error, copy violation - servers `jupiter' and `pluto'
have the same software enabler code, `a1b2c3d4f5g6h7j8' (13)
* mars:/var save: cannot start a save for /var with NSR server `jupiter'
* mars:index save: cannot start a save for /usr/nsr/index/mars with NSR
server `jupiter'
* mars:index save: cannot start a save for bootstrap with NSR server
`jupiter'
* mars:index save: bootstrap save of server's index and volume
databases failed

バックアップを実行し直すには、nsr_shutdown コマンドを使って各サーバーを停止させ、余分なサーバーから Backup ソフトウェアを削除して、バックアップを実行するサーバーだけで Backup デーモンを再起動します。

Xview のエラー

クライアントマシンから Backup 管理プログラムの nwadmin を使ってグラフィカルな管理インタフェースを起動しようとしたときに、次のエラーメッセージが表示された場合、そのクライアントは Backup の表示の許可が与えられていません。


Xlib: connection to "mars:0.0" refused by server
Xlib: Client is not authorized to connect to Server
Xview error: Cannot open display on window server: mars:0.0 (Server
package)

この問題を解決するには、次の手順に従います。

  1. クライアントマシンから、次のように xhost コマンドを起動します。


    # xhost server-name

  2. Backup サーバーにリモートからログインして、シェルプロンプトで次のように setenv コマンドを入力します。


    # setenv DISPLAY client-name:0.0

    /usr/bin/csh 以外のコマンドシェルの場合は、次のように入力します。


    # DISPLAY=client-name:0.0 
# export DISPLAY

クライアント/サーバー間通信

Backup の設定と構成の際に Backup ユーザーによって報告される問題の多くは、ネットワーク内の通信に関するものです。この節では、ネットワーク内の通信を検査する手順を説明します。

IP エラーを障害追跡するには

IP エラーを障害追跡するには、次の手順に従います。

  1. ご購入先に連絡する場合に備えて、対処した手順とその結果およびエラーメッセージを記録しておきます。

    必要な場合は、直接ご購入先に電子メールまたはファクシミリで送ってください。

  2. Backup クライアントとサーバーの両方に、ホストテーブルを設定します。

    次の 「ホストテーブルを構成するには」を参照してください。

  3. 検査を簡単にするため、ほかのネームサーバーを無効にします。

    詳細は、「障害追跡でのネームサーバーの無効化」を参照してください。

  4. ping コマンドを使って基本的な接続を確認します。

    詳細は、「ping コマンドを使ってネットワーク接続を検査するには」を参照してください。

  5. rpcinfo コマンドを使って、セッションが確立されていることと、ポートマッピングが正しいことを確認します。

    詳細は、「rpcinfo コマンドを使ってセッション確立を検査するには」を参照してください。

ホストテーブルを構成するには

IP 関連の問題の障害追跡には、ホストテーブルだけを使用することをお勧めします。しかしこれは、たとえば DNS などのネームサービスが Backup では使えない、ということではありません。Backup が正しくインストールされていることを確認する場合には、ホストテーブルだけを使います。Backup がホストテーブルで正しく動作することがわかったら、使用しているネームサーバーを有効にしてかまいません。

サーバーまたはクライアントでホストテーブルを構成するには、次の手順に従います。

  1. Backup クライアントで、その Backup クライアントそのものと、それが接続されている Backup サーバーを一覧表示させます。

    次に例を示します。


    127.0.0.1 localhost loopback
123.456.789.111 client client.domain.com
123.456.789.222 server server.domain.com

  2. Backup サーバーで、その Backup サーバーそのものと、それに接続されているすべてのクライアントを一覧表示させます。

    次に例を示します。


    127.0.0.1 localhost loopback
123.456.789.111 server server.domain.com
123.456.789.222 client client.domain.com

  3. 「ping コマンドを使ってネットワーク接続を検査するには」のガイドラインに沿って、各オペレーティングシステムでもっとも成功率の高いホストテーブルの構文解析方法を確認します。

    ホストテーブル構成での注意事項を次に示します。

    • ホストテーブルの本体 (ボディ) 部分には、空行は使わないでください。

    • ホストテーブルの最後には、必ず空行を入れます。

    • 手順 1 および 2 に示した順序と形式に従ったうえで、注釈のない最初のエントリは必ずループバック行にしなければなりません。

    • 注釈のない各行の最後の文字は、改行ではなく空白にしなければなりません。

    UNIX プラットフォームの場合は、ホストテーブルは /etc/hosts ファイルにあります。

    ホストテーブルは、必要に応じて DNS とともに使用できますが、障害追跡を容易にするためには、一時的に DNS を無効にします。

障害追跡でのネームサーバーの無効化

名前解決における問題の障害追跡を容易にするために、DNS、WINS、DHCP といったサービスを無効にすることをお勧めします。名前解決において問題が起こった場合は、まず使用しているマシンのホストテーブルだけを構成し、次にバックアップを検査します。

DNS、WINS、DHCP の各サービスで起こりうる共通の問題として、次のものがあります。

DNS はネットワーク全体で無効にする必要はなく、検査する Backup クライアントと Backup サーバーの最初の設定時にだけ無効にしてください。クライアントの機能のうち、DNS サーバーから IP の命名情報を取得する機能だけを無効にします。通常は、DNS サーバーそのものを無効にする必要はありません。

大部分の UNIX プラットフォームの DNS サーバーを無効にするには、/etc/resolv.conf ファイルの名前を変更して再起動します。

Solaris の場合には、resolv.conf ファイルの名前を変更する代わりに、DNS サービスの前にホストテーブルが検索されるように、IP 名の検索順序を設定することができます。

IP 名の検索順序を設定するには、次の手順に従います。

  1. /etc/nsswitch.confファイルを編集して、/etc/resolv.conf ファイルがあることを確認します。

  2. ホストファイルが先頭、2 番目が DNS、最後が NIS になるように、検索順序を指定します。

    次に例を示します。


    hosts: files [NOTFOUND=continue] DNS [NOTFOUND=continue] nis

ping コマンドを使ってネットワーク接続を検査するには

ホストテーブルを作成したら、ping コマンドを使って接続を検査します。

Backup クライアントでの操作


# ping mars
# ping mars.oak.com

Backup サーバーでの操作 (サーバーが唯一のクライアントである場合は、アスタリスク (*) を付けた手順だけを実行)

rpcinfo コマンドを使ってセッション確立を検査するには

ping コマンドによって接続が確認されたにも関わらず、依然としてバックアップの問題が解決できない場合は、rpcinfo コマンドを使って検査することもできます。Backup はポートのマッピングに非常に大きく依存しているので、rpcinfo コマンドを使ってポートマッパの動作を調べます。ping コマンドは、OSI モデルで言えばネットワーク層までの接続を検査するもので、rpcinfo コマンドは、そのセッション層までの通信を調べるものと言えます。

rpcinfo コマンドによる検査は、ping コマンドの場合と同じです。サーバーそのものが唯一のクライアントである場合は、前述の操作のうちアスタリスク (*) を付けた検査だけを行います。

rpcinfo コマンドを実行するためには、コマンド行にホスト名が入力されるマシンにおいてポートマッパが稼働していなければなりません。Sun のポートマッパは、ほとんどの場合、完全な機能を備えた Sun 以外のベンダー製のポートマッパ と互換性があります。独自のポートマッパ付きの製品を使用している場合は、Backup が環境内のほかの部分に対しても動作することが検証されるまでは、サードパーティのポートマッパをロードしないことをお勧めします。これで、未知のポートマッパを追加せずにポートマッパの互換性を検証できます。

Solaris では、rpcbind デーモンが動作していなければなりません。rpcinfo ユーティリティは、オペレーティングシステムの一部に組み込まれています。

TCP を使用しているポートを表示するための rpcinfo コマンドの構文は、次のとおりです。


rpcinfo -p hostname

ping コマンドの場合と同様に、hostname 変数の位置にロングネームとショートネームを指定します。

そのほかの rpcinfo コマンド行オプションを表示するには、コマンド行に rpcinfo と入力します。rpcinfo コマンドについての注意とエラーメッセージは、UNIX の rpcinfo のマニュアルページを参照してください。このマニュアルの ping の説明で示したすべてのサーバーおよびクライアントの位置を繰り返し指定して、rpcinfo コマンドを入力してください。

rpcinfo コマンドが正常に実行されると、ポートの番号と名前が一覧表示されます。障害追跡で必要となるのは、エラーメッセージの正確なテキストです。rpcinfo コマンドに対する正常な応答の一般的な形式は、次のとおりです。


rpcinfo for mars
program vers proto   port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper
390103    2   tcp    760
390109    2   tcp    760
390110    1   tcp    760
390103    2   udp    764
390109    2   udp    764
390110    1   udp    764
390113    1   tcp   7937
390105    5   tcp    821
390107    4   tcp    819
390107    5   tcp    819
390104  105   tcp    822

スイッチとルーターのファームウェアの検査

あるべンダーのスイッチまたはルーターを使用している場合は、RPC (遠隔手続き呼び出し) のトラフィックが正常に処理されていることを確認するため、ネットワーク上のすべてのスイッチまたはルーターのファームウェアが、1995 年 8 月以降に作成されたものかどうかを調べます。スイッチベンダーとルーターベンダーの多くは、1995 年 8 月以降に、RPC トラフィックの処理能力を大きく向上させました。

命名の要件

UNIX 版 Backup クライアントのリリース 4.2 以降では、/nsr/res サブディレクトリにある servers ファイルを使って、Backup サーバーがクライアントのデータをバックアップする許可を与えられているかどうかを判断します。servers ファイルがない場合は、好みのエディタを使って、そのファイルを /nsr/res に作成できます。

クライアント上の servers ファイルに、クライアントのデータをバックアップしたいサーバーのショートネームとロングネームの両方が記載されていることを確認します。たとえば、oak.com というドメインにある mars という Backup サーバーは、Backup クライアントの servers ファイルに次のように記載されます。


mars
mars.oak.com

「Clients」リソースでショートネームとロングネームの両方を指定し、各クライアントに該当するほかの別名があれば、それらも「Alias」属性に指定します。

サーバーエラーとの関連付け

Backup は、クライアント/サーバーモデルに対応しています。このモデルでは、RPC によってサーバーがクライアントにサービスを提供します。これらのサービスは、長期間存続するプロセスであるデーモンの内部で存続します。

クライアントがデーモンを探し出すためには、デーモンを登録サービスに登録しておかなければなりません。デーモンは、起動時に、ポートマッパが提供する登録サービスに自動的に登録されます。

Backup サーバーは、バックアップと復旧の両方のサービスを提供します。Backup サーバーはクライアントからデータを受け取り、バックアップメディアに保存し、要求があった時点で取り出します。Backup デーモンが動作していないときに Backup サービスが要求されると、セーブグループ完了メールに次のメッセージが表示されます。


Server not available
RPC error, remote program is not registered

これらのメッセージは、Backup デーモンである nsrd、nsrexecd、nsrindexd、nsrmmd、および nsrmmd が動作していない可能性があることを示しています。デーモンを再起動するには、スーパーユーザーになって、シェルプロンプトで次のコマンドを入力します。


# /etc/init.d/networker start

リモートファイルシステムの保存

リモートクライアントのバックアップが失敗すると、セーブグループ完了メールに、次のようなエラーメッセージが表示される場合があります。


All: host hostname cannot request command execution
All: sh: permission denied

最初のメッセージは、クライアント上の nsrexecd デーモンが、サーバーがクライアントのファイルをバックアップできるように構成されていないことを意味しています。2 番目のメッセージは、クライアント上で現在 nsrexecd デーモンが動作していないことを意味しています。

これらの問題を解決するには、クライアント上で nsrexecd デーモンが動作していることを確認し、サーバーのホスト名がブート時ファイルに記載されていることを確認します。ブート時ファイルは、インストールスクリプトが終了する前に自動的に作成され、バックアップのためにクライアントと交信するすべてのサーバー名をユーザーに尋ね、ユーザーが応答するサーバー名を優先度の順に並べます。表 C-1 にブート時ファイルのディレクトリを示します。

nsrexecd デーモンの詳細は、nsrexecd(1m) のマニュアルページを参照してください。

表 C-1 ブート時ファイルのディレクトリ

オペレーティングシステム 

ブート時ファイル 

Solaris 

/etc/rc2.d/S95networker

SunOS 4.1.x 

/etc/rc.local

リモート復旧のためのアクセス権

「Client」リソースを構成することにより、復旧に必要なクライアントへのアクセスを制御できます。復旧のためにクライアントのセーブセットにアクセスできるユーザー名が、「Remote Access」リストに表示されます。ファイルに必要なセキュリティレベルに応じて、ユーザー名を追加したり削除したりできます。

次に示すユーザーは、「Remote Access」リストの内容にかかわらず、どのクライアントのどのファイルでも復旧できます。

これら以外のユーザーは、ファイルがバックアップされた時点でのファイルのモードと所有者に応じて、読み取りを許可されているファイルだけを復旧できます。スーパーユーザー、オペレータ、オペレータグループ以外のユーザーがファイルを復旧すると、そのユーザーがファイルを所有します。

オートチェンジャの操作

この節では、Backup でオートチェンジャを使用する場合に起こる問題の解決法を説明します。

デバイスドライバのインストールの検査

Backup デバイスドライバソフトウェアをインストールしたあと、lusdebug プログラムを使ってサーバーとの接続を検査し、jbexercise プログラムを使ってオートチェンジャを検査します。次に示すコマンドの control-port に、たとえば scsidev@0.6.0 などの、使用しているオートチェンジャに割り当てられている制御ポートの番号を指定します。 


# lusdebug control-port 0
# jbexercise -c control-port -m model

これらのコマンドの実行が失敗した場合やエラーメッセージが表示された場合には、以降の節の説明を参考にして、原因を追及し、解決してください。

lusdebug コマンドが失敗する

lusdebug コマンドが失敗した場合は、次のヒントを参考にして、考えられる問題を特定し、解決をはかります。


scsidev@0.6.0:<EXABYTE EXB-10i EXB-10i >

このメッセージの情報に誤りがないことを確認します。

ベンダー名とモデル名が正しくない場合は、ドライバのインストール時に、デバイス ID に誤った SCSI ID を指定しています。インストールスクリプトでは、テープドライブではなく、機械的な機構の SCSI ID の指定が求められます。

上記の対応で問題が解決しないときは、ご購入先にお問い合わせください。その際は、「ご購入先に連絡する前に揃えておく情報」で説明した情報と、sjiinq および sjirjc の各プログラムの出力結果を提示してください。これら 3 つのプログラムの詳細は、付録 B 「コマンド行リファレンス」の該当箇所か、または各プログラムのマニュアルページを参照してください。

jbexercise コマンドが異常終了する

jbexercise コマンドが異常終了した場合は、次のヒントを参考にして考えられる問題を特定し、解決をはかります。

上記の対応で問題が解決しないときは、ご購入先にお問い合わせください。その際は、「ご購入先に連絡する前に揃えておく情報」で説明した情報と、jbexercise、sjiinq、sjirjc の各プログラムの出力結果を提示してください。これら 3 つのプログラムの詳細は、付録 B 「コマンド行リファレンス」の該当箇所か、または各プログラムのマニュアルページを参照してください。

自動検出 SCSI ジュークボックスオプションを使うとサーバーがハングする

jb_config オプションを使って自動検出 SCSI ジュークボックスをインストールしている場合にサーバーがハングしたときには、次の対策をお勧めします。

  1. SJI ジュークボックスをインストールするための jb_config オプションを選択します。ジュークボックスの一覧が表示されます。

  2. これからインストールするジュークボックスのタイプに該当する番号を入力します。

  3. 次のメッセージが表示されるまで、jb_config オプションを続行させます。


    Jukebox has been added successfully.

オートチェンジャのインベントリ作成での問題

次のいずれかの状況では、オートチェンジャのインベントリが無効となるため、Backup でそのオートチェンジャを使用できなくなります。

オートチェンジャを再び使用できるようにするには、次の手順に従います。

  1. メディアカートリッジが正しくオートチェンジャ内に取り付けられていて、オートチェンジャのドアが閉まっていることを確認します。

  2. Backup サーバーのスーパーユーザーになります。

  3. 次のようにして、オートチェンジャをリセットします。


    # nsrjb -Hv

  4. 次のようにして、インベントリを作成します。


    # nsrjb -Iv

    インベントリの作成が完了すると、再び Backup でオートチェンジャが使用できるようになります。

    nsrjb コマンドの使用法の詳細は、nsrjb(8) のマニュアルページか、または 第 7 章「オートチェンジャモジュール」を参照してください。

「Destination component full」メッセージ

通常、「Destination component full」のメッセージが表示されるのは、たとえば Backup を使ってボリュームのマウントを解除せずに、オートチェンジャのボタンを押して物理的にテープドライブをアンロードするといった、手動の操作をした場合です。このような操作をすると、オートチェンジャ内のメディアの状態を Backup は追跡できなくなります。

この問題を解決するには、Backup の nsrjb -H コマンドを使ってオートチェンジャをリセットします。

テープ容量のすべてを使用できない

Backup がテープ容量のすべてを使用できないことがあります。たとえば、公称容量 4000M バイト のテープにまだ 3000M バイトのデータしか書き込んでいないのに「full」マークが付けられることがあります。

Backup でテープを容量いっぱいまで使うには、現在のデバイスに適した最高の密度で書き込まれたデバイスドライバを選択します。テープにラベルを付けるときに、そのデバイスがサポートしている最高密度が Backup によって書き込みに使用されます。

テープの全容量が使われていないのにいっぱいになったとみなされる原因としては、次のものがあります。

サーバーが、オートチェンジャのコントロールポートにアクセスできない

コントロールポートによって、オートチェンジャの装着機能を制御します。コントロールポートが正しく接続されていることを確認する方法は、オートチェンジャのハードウェアインストールマニュアルに記載されています。コントロールポートが動作しているかどうかを判断できない場合は、オートチェンジャのベンダーにお問い合わせください。

Backup によるアーカイブと取り出し

この節では、Backup によるアーカイブと取り出しの際に起こる可能性のある問題の障害追跡方法を説明します。

サーバーによるリモートからのアーカイブ要求が失敗する

リモートのワークステーションから送られるアーカイブ要求を Backup サーバーから実行できない場合は、たとえば root などのアーカイブのクライアントのユーザー名が、「Clients」リソースの「Archive Users」属性に記載されていない可能性があります。

root@client-system に対しても、「Server」リソースの「Administrator」属性を指定することによって、Backup の管理特権を与えることができます。Backup 管理者は、ほかのクライアントのほかのユーザーが所有しているデータを復旧し、取り出すことができるので、管理特権を与えることにより、セキュリティ上の問題が出てきます。

複数のセーブセットが 1 つのアーカイブセーブセットに見える

複数のセーブセットを、/home または /usr として 1 つのアーカイブにまとめると、それらは 1 つのアーカイブセーブセットとなり、Backup Retrieve プログラム nwretrieve の「Archives」リストに「/」として表示されます。

複数のセーブセットを別々に分けて取り出す場合は、それらを別々にアーカイブします。

アーカイブのクローンが「Backup Retrieve」ウィンドウに表示されない

Backup Retrieve プログラムの nwretrieve で注釈を検索する場合、アーカイブのクローンは「Archives」属性に表示されません。

クローンを探すには、「Search Annotation」属性を指定しないで照会を始めます。照会の結果、あまりにも多くのアーカイブが表示されるようなら、mminfo コマンドを使って、必要なアーカイブと同じセーブセット ID (ssid) を持つアーカイブクローンだけを探すこともできます。

誤ったアーカイブプールが選択される

複数のアーカイブプールを作成すると、アーカイブ用に、デフォルトのアーカイブプールは選択されません。アーカイブ用に選択されるのは、作成された最後のプールです。

2 番目のアーカイブ要求が実行されない

同じ名前のアーカイブ要求を 2 つ作成すると、実行されるのは最初の要求だけです。これを避けるには、同じ名前のアーカイブ要求を 2 つ作成しないでください。2 番目の要求は実行されません。

コマンド行からのアーカイブが即時に起動しない

コマンド行から nsrarchive を実行する場合、注釈を入力して、Ctrl+D キーを押してアーカイブを起動しようとしても、アーカイブは即時には起動しません。アーカイブの起動には遅れがあるので、しばらく待たなければなりません。Ctrl+D キーを、何回も押さないでください。

検索リスト内に空の注釈がある

検索文字列を使って注釈を探す場合、検索リストに空の注釈が見つかる場合があります。

Backup Archive プログラムでは、空の注釈文字列を入力できません。一方、DOS、Windows、または NetWare にインストールされている旧バージョンの Backup Archive ソフトウェアには、注釈の機能がありません。したがって、旧バージョンのソフトウェアを使ってアーカイブされたセーブセットの注釈は、検索リストでは空の文字列になります。

診断ツール

オペレーティングシステムのサービスとして、さらに Backup 製品の一環として、さまざまな診断ツールが使用できます。この節では、Backup に役立つ診断ツールをいくつか説明します。

診断レポート

Backup には、広範囲の内容の診断レポートを生成できる nsr_support という名前のスクリプトが用意されています。通常 nsr_support を実行するのは、ご購入先から要請があった場合だけです。スクリプトの出力をファイルにリダイレクトし、そのファイルをご購入先に電子メールで送って分析を依頼します。このスクリプトを実行して出力をリダイレクトするには、システムのスーパーユーザーになって、シエルプロンプトで次のように nsr_support コマンドを入力します。 


# nsr_support -f /temp/filename

nsr_support コマンドの詳細は、nsr_support のマニュアルページを参照してください。

通信テスト

通信セッションが確立されていることを確認するには、ping コマンドと rpcinfo コマンドを使います。どちらのツールもオペレーティングシステムのソフトウェアとして提供されています。

Backup は、ポートのマップに依存しているので、rpcinfo コマンドを使ってポートマッパの動作を検査します。OSI モデルで言えば、ping コマンドでネットワーク層までの接続を検査し、rpcinfo コマンドでセッション層までの通信を検査します。ping と rpcinfo のコマンドの使用法は、「クライアント/サーバー間通信」を参照してください。

通信のテストにさらに他のツールが必要な場合は、ご購入先にお問い合わせください。