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) |
クライアントの別名に関する問題の原因
次に示すいずれかの状況が発生したら、クライアントの別名に関する問題が原因になっていると考えられます。
-
エラーメッセージ「No client resource for...」または「Client xxx cannot back up client yyy files.」が表示される
-
スケジュールされたバックアップのレベルにかかわらず、クライアントマシンがいつもフルバックアップだけを実行する
-
自動インデックス管理が、ブラウズポリシーと保持ポリシーのとおりに行われていないようにみえる。これは、インデックスを格納しているファイルシステムのサイズが大きくなり続けていることからわかる
-
インデックスが置かれているディレクトリ /nsr/index の中に、同じクライアントに対して異なるクライアント名のディレクトリが 2 つある
次に示すマシンとサイトでは、クライアントの別名を変更する必要があります。
-
複数のネットワークインタフェースを持っているマシン
-
同じマシンに、たとえば jupiter と jupiter.oak.com のように、短いホスト名と「完全指定の」ホスト名を混在させて使用しているサイト
-
YP (NIS) と DNS の両方を使用しているサイト
この問題を抱えているクライアントのクライアントリソースを編集するには、Backup 管理プログラムか、nsradmin を実行します。このホストのすべてのネットワーク名を「Aliases」属性に追加します。
注意 - ほかのホストによって共有されている別名は、この行に指定しないでください。
構成で使用できない文字
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 は、自分がバックアップするすべてのクライアントのクライアントファイルインデックスを保守しています。クライアントの名前を変更すると、そのクライアントのインデックスは新しいクライアント名と関連付けられず、古いクライアント名でバックアップされているファイルの復旧ができなくなります。新たに名前変更したクライアントで古いバックアップデータを復旧する場合は、「古いバックアップデータを新しいクライアント名で復旧するには」を参照してください。.
古いバックアップデータを新しいクライアント名で復旧するには
-
古いクライアント名で構成されている「Client」リソースを削除します。
-
新しいクライアント名の「Client」リソースを新しく作成します。
-
次のようにして、Backup デーモンを停止させます。
# nsr_shutdown
-
新しいクライアント用に自動的に作成されたインデックスディレクトリを削除します。
ただし、単に古いクライアントのインデックスディレクトリに新しいクライアントインデックスをコピーしても、新しいクライアントインデックスが古いクライアントのインデックスディレクトリの内部にネストされるだけです。
-
次のように 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 コマンドまたは nsrjb コマンドを使ってテープにラベルを付ける場合
nsrmm: error, label write, No more processes (5) |
-
scanner -i コマンドを使おうとした場合
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) |
この問題を解決するには、次の手順に従います。
- © 2010, Oracle Corporation and/or its affiliates