6    トラブルシューティング

この章では,起こり得る問題からの回復手順と,問題の修復または回避手順について説明します。 この章で取り上げるトピックは次のとおりです。

6.1    ユーザ・ファイルの復旧

ユーザ・ファイルの復旧について,あらかじめ計画を立てておかない限り,削除されたファイルを復旧する簡便な手段はありません。 次の 3 つの方法のいずれかで,削除されたファイルにアクセスできます。

ファイルが削除されたときに,バックアップもゴミ箱もクローンもない場合,ファイルを復旧する手段はありません。 しかし,ファイルが壊れている場合,/sbin/advfs/salvage コマンドを実行することで内容を部分的に復旧できる場合があります。 手順については,6.2.6 項を参照してください。

6.2    一般的な復旧手順

次の復旧手順は,すべてのドメイン・パニックと多くのシステム・クラッシュに適用できます。 クラッシュが 1 つのドメインによって発生しているならば,次に示す手順によって,そのドメインのファイルセットに再びアクセスできるようになります。 必要なステップまでを行なってください。 すべてのステップを行なう必要は必ずしもありません。 ルート・ドメインを復旧する場合は,6.3.4 項を参照してください。

6.2.1    問題の報告のためのデータの保存

sys_check ユーティリティに -escalate オプションを指定して実行し,技術サポート担当者に報告するエスカレーション・ファイルを作成します。 このユーティリティは,収集したデータを/TMPDIR/escalate.tar ファイルとして出力します。

sys_check コマンドは,SysMan Menuの「サポートとサービス -- エスカレーション・レポートの作成」ユーティリティ (付録 Aを参照)を使用をして実行するか,コマンド行から実行します。

sys_check ユーティリティを実行するには,root ユーザまたは適切な特権が必要です。 詳細については, sys_check(8)を参照してください。

6.2.2    システム・メタデータのコピーの保存

ドメインが,破損しているか,何らかの問題の原因になっていると思われる場合は,/sbin/advfs/savemeta コマンドを実行します。 これにより,サポート担当者が調査するための,ドメインのメタデータのコピーが保存されます。 savemeta コマンドに -f オプションを指定して実行すると,それぞれのファイルセットのフラグ・ファイルから構造情報を保存します。 このユーティリティは,ログ・ファイル,ビットファイル・メタデータ・テーブル,各ボリュームのストレージ・ビットマップ,ドメインのルート・タグ・ファイル,およびファイルセット・タグ・ファイルを保存します。

たとえば,domain_1 のメタデータを/tmp/saved_domain_1 に保存するには,次のコマンドを入力します。

# /sbin/advfs/savemeta domain_1 /tmp/saved_domain_1

ファイルセット fsetN のフラグ・ファイルから,メタデータを /tmp/saved_fsetN に保存するには,次のコマンドを入力します。

# /sbin/advfs/savemeta domain_1 -f fsetN /tmp/saved_fsetN

このコマンドを実行するには,root ユーザの特権が必要です。 詳細については, savemeta(8)を参照してください。

6.2.3    ダメージを受けていないファイルの保存

影響のあるドメインのできるだけ多くのファイルセットをバックアップすることをお勧めします。 バックアップ方式については,第 4 章 を参照してください。 ドメインを再作成するのに,このバックアップ,他の最新のバックアップ,および復旧ユーティリティ (/sbin/advfs/verify/sbin/advfs/fixfdmn,および /sbin/advfs/salvage) の出力を使用することができます。

6.2.4    ファイル・システムの整合性の確認

メタデータの整合性を維持するため,/sbin/advfs/verify コマンドを実行して,ファイル・システムの構造を確認します。 verify コマンドを実行すると,ビットファイル・メタデータ・テーブル (BMT),ストレージ・ビットマップ,タグ・ディレクトリ,フラグ・ファイルなどのディスク構造がファイルセットごとにチェックされ,ディレクトリ構造が正しいかどうか,すべてのディレクトリ・エントリが有効なファイルを参照しているかどうか,およびすべてのファイルにディレクトリ・エントリがあるかどうかを確認できます。 このコマンドを実行するには,root 権限が必要です。

verify コマンドは,次のような場合に実行します。

SysMan Menuの「AdvFS ドメインの管理」ユーティリティ (付録 A参照) を使用するか,コマンド行で次のように verify コマンドを実行します。

/sbin/advfs/verify domain_name

verify コマンドは,ファイルセットを特殊なディレクトリにマウントします。 ドメイン障害のために verify コマンドでファイルセットをマウントできない場合には,最後の手段として verify コマンドに -F オプションを指定して実行します。 -F オプションを指定した場合,verify コマンドは mount コマンドの -d オプションを使用してファイルセットをマウントします。 つまり,AdvFS は当該ドメインを復旧せずに,トランザクション・ログ・ファイルを初期化します。

注意

verify コマンドに -F オプションを指定しすると,直前の不完全な動作に対するドメインの復旧処理が行われないため,データが破損するおそれがあります。

状況によっては,verify コマンドでファイルセットがアンマウントされないことがあります。 その場合には,ファイルセットを手動でアンマウントし,/etc/fdmns ファイル内に作成されているマウント・ポイントを削除する必要があります。

ファイル数が数百万にも及ぶマシンで verify コマンドを正常に動作させるためには,同コマンドに十分なスワップ領域を割り当てる必要があります。 verify ユーティリティに必要なメモリ・サイズがカーネル変数の proc/max_per_proc_data_size プロセス変数の値を超過している場合には,このユーティリティは正常に終了しません。 この問題に対処するには,ドメイン・サイズの 10% までスワップ領域の割り当てを増やして verify コマンドを実行します。 詳細については, swapon(8)を参照してください。

verify コマンドが成功した場合,クラッシュをまねいたイベントが繰り返されたときのために,ドメインをバックアップすることをお勧めします。

setxsety という 2 つのファイルセットを含むドメイン domainx を,verify コマンドでチェックしたときの出力例を次に示します。

# /sbin/advfs/verify domainx
+++Domain verification+++
Domain Id 2f03b70a.000f1db0
Checking disks ...
Checking storage allocated on disk /dev/disk/dsk10g
Checking storage allocated on disk /dev/disk/dsk10a
Checking mcell list ...
Checking mcell position field ...
Checking tag directories ...
 
+++ Fileset verification +++
+++ Fileset setx +++
Checking frag file headers ...
Checking frag file type lists ...
Scanning directories and files ...
     1100
Scanning tags ...
     1100
Searching for lost files ...
     1100
 
+++ Fileset sety +++
Checking frag file headers ...
Checking frag file type lists ...
Scanning directories and files ...
     5100
Scanning tags ...
     5100
Searching for lost files ...
     5100

この例では,ドメインに問題は見つかっていませんので,復旧手順を行なう必要はありません。 詳細については, verify(8)を参照してください。

6.2.5    fixfdm ユーティリティを使用したディスク上のメタデータ損傷への対処

/sbin/advfs/fixfdmn ユーティリティは,壊れたメタデータを修復することによってドメインを使用可能な (マウント可能な) 状態にすることを主な目的として設計されています。 次の状況で,ファイルセットをアンマウントし,このユーティリティを実行します。

fixfdmn ユーティリティはメタデータを走査し,壊れたメタデータを検索して,利用可能なメタデータが十分ある場合,これを修復しようとします。 利用可能なメタデータが十分にない場合は,できるだけ壊れたメタデータを移動または削除し,さらに必要に応じてファイルを削除することによって損傷部分を取り除こうとします。

このユーティリティは,ファイルの内容のチェックと修正は行いません。 ファイルからデータを復元することが急務である場合や,ドメインの大きな部分が壊れてしまった場合は,/sbin/advfs/salvage ユーティリティの使用法について,6.2.6 項 を参照してください。

fixfdmn ユーティリティを実行した後は,ファイルセットを再度マウントします。 ファイルセットを再マウントできたら,ファイルが削除されていないかチェックします。 削除されている場合,バックアップからリストアします。 ファイルセットをマウントできない場合,fixfdmn コマンドに -u オプションを指定してプロセスを取り消し,salvage コマンドで変更のないデータにアクセスできるようにします。

fixfdmn コマンドが成功した場合,クラッシュをまねくイベントが繰り返されたときのために,ドメインをバックアップすることをお勧めします。 fixfdmn コマンドが成功すれば,さらに回復手順を実行する必要はありません。

fixfdmn コマンドに -n オプションを指定すると,ドメインをチェックだけして,修復は行なわれません。 システム・メッセージを出力だけし,変更をディスクに書き込みません。

6.2.6    損傷したドメインからのファイル・データの救済

ドメインのファイルを復旧するには,/sbin/advfs/salvage ユーティリティを使用します。 このコマンドは,壊れたドメインから救済可能なファイルを抽出し,復旧したファイルを置くためのファイルセットにそれらをコピーします。 ドメインの損傷の性質によっては,すべてのデータを救済できる場合もあれば,いくつかしか救済できない場合もあります。

/sbin/advfs/fixfdmn コマンドを実行し,成功しなかった場合,salvage コマンドを実行する前に,まず fixfdmn コマンドに -u オプションを指定して実行し,このユーティリティが行なった変更を元に戻す必要があります。

salvage 機能を使用するには,SysMan Menuの「AdvFS ドメインの管理」ユーティリティ (付録 Aを参照) を使用するか,コマンド行で次のように salvage コマンドを実行します。

/sbin/advfs/salvage domain_name fileset_name

復元されたデータのコピー先には,ディスクとテープのどちらでも使用できます。 復元できるデータの量は,ドメインの損傷の種類によって左右されます。 詳細については, salvage(8) を参照してください。

salvage コマンドを実行しても,ドメインのすべてのデータを復旧できるという保証はありません。 ファイル,ディレクトリ,ファイル名,またはファイルの一部が失われる可能性もあります。 このユーティリティは,復元されたファイルの状態を記録したログ・ファイルを生成します。 -l オプションを指定すると,このユーティリティが処理したすべてのファイルがログ・ファイルに記録されます。

salvage コマンドは,復元したファイルを,ファイルセット名に基づいて付けられた名前のディレクトリに格納します。 salvage コマンドはファイルセットごとにlost+found ディレクトリを作成し,その中に親ディレクトリが見つからないファイルを格納します。 復元されたファイルセット・ディレクトリが配置されるディレクトリのパス名は明示的に指定できます。 このディレクトリを指定しない場合,salvage コマンドは,復元したファイルセットを現在の作業ディレクトリの下に格納します。

-F tar オプションを指定することによって,損傷のあるドメインから復元したデータを,tar 形式でテープに格納することも可能です。

6.2.6.1    ファイル・データの復元

最新のバックアップ・ソースがある場合,/sbin/advfs/salvage ユーティリティに -d オプションを指定して,バックアップの日付以降に変更されたデータのみを復元することができます。 これによって salvage ユーティリティが処理しなければならないデータ量を軽減することができます。 バックアップ・ソースがない場合は,指定したドメインのすべてのファイルに対して,salvage ユーティリティを実行します。

システムに,復旧するすべてのファイルを保持するスペースがない場合は,データをテープに復元し,その後に元のディスクの場所に読み込むことができます。 また,salvage コマンドを -F オプションと -f オプションを指定して実行し,データを tar 形式で復元することもできます。

この手順は,次のとおりです。

  1. 破損したドメインのすべてのファイルセットをアンマウントします。

  2. 救済するデータをテープに保存する場合,ローカル・ドライブにテープを装着します。 詳細については,『ハードウェア管理ガイド』を参照してください。

  3. tar 形式でデータを救済しない場合は,復旧した情報を一時的に保持するドメインとファイルセットを作成し,ファイルセットをマウントします。

  4. salvage コマンドを実行します。

  5. salvage.log ファイルを調べ,すべての必要なファイルを復旧したかを確認します。 失われたファイルがある場合,バックアップ・ソースから,それらを探す必要があります。

  6. ドメインとマウント・ポイント・ディレクトリを再度作成します。 ファイルセットを作成し,そこにマウントします。

  7. バックアップからファイルをリストアします。

  8. 救済したファイルを,一時的ドメインまたは tar ファイルからリストアします。

次の例では,ドメインをディスクに救済しています。 壊れたドメインは PERSONNEL で,このドメインにはファイルセット personnel_a-e があり,/personnel_a-e にマウントされています。 元のドメインは,ボリューム /dev/disk/dsk12c にあり,salvage コマンドの出力は,/dev/disk/dsk3c に置かれます。 バックアップ・テープ /dev/tape/tape0 が利用できるので,損傷した PERSONNELドメインから,2001 年 12 月 5 日の午後 1 時 30 分 (最後にバックアップした日時) 以降に変更されたファイルだけを抽出します。 ドメインは元のボリュームにリストアされます。

# umount /PERSONNEL
# mkfdmn /dev/disk/dsk3c RECOVER
# mkfset RECOVER recover_fset
# mkdir /recover
# mount RECOVER#recover_fset /recover
# /sbin/advfs/salvage -d 200112051330 -D /recover PERSONNEL
salvage: Domain to be recovered 'PERSONNEL' 
salvage: Volume(s) to be used '/dev/disk/dsk12c'
salvage: Files will be restored to '/recover' 
salvage: Logfile will be placed in './salvage.log' 
salvage: Starting search of all filesets: 09-Dec-2001
salvage: Starting search of all volumes: 09-Dec-2001
salvage: Loading file names for all filesets: 09-Dec-2001
salvage: starting recovery of all filesets: 09-Dec-2001

mkfdmn コマンドを実行する前に,salvage.log ファイルを表示して,必要なすべてのファイルが復元されたことを確認します。 失われたファイルがある場合,salvageコマンドの -d オプションにもっと前の日付を指定して実行することで,さらに情報を取得できる場合があります。 新しいドメインを作成すると,salvage を再び実行することはできません。 ただし,6.2.6.3 項に説明するように,-S オプションを指定して実行することはできます。

# mkfdmn /dev/disk/dsk12c PERSONNEL
# mkfset PERSONNEL personnel_a-e
# mkdir /personnel_a-e
# mount PERSONNEL#personnel_a-e /personnel_a-e
# vrestore /dev/tape/tape0 /personnel_a-e
# cp -Rp /RECOVER/personnel_a-e/* /personnel_a-e
# umount /recover
# rmfdmn RECOVER
rmfdmn: remove domain RECOVER [y/n] y
rmfdmn: domain RECOVER removed.

6.2.6.2    破損したルート・ドメインからのデータの復元

ルート・ドメインが破損してシステムをブートできない場合,インストール CD-ROM からシステムをブートし,/sbin/advfs/salvage コマンドを使用することができます。 6.3.4 項の手順に従ってください。 ルート・ドメインの損傷の種類と程度によって,ファイルの復旧が成功するかは左右されます。

6.2.6.3    ブロック単位でのデータの復元

salvage ユーティリティを実行しても復元できないファイルが大量にある場合は,salvage コマンドに -S オプションを指定して実行します。 この処理では,ユーティリティがすべてのディスク・ブロックを少なくとも一度は読み取ることになるため,完了までにかなりの時間を要します。

注意

正常なドメインに対して誤って mkfdmn コマンドを実行してしまった場合は,salvage コマンドに -S オプションを指定して実行する以外にファイルを復元する方法はありません。

注意

salvage ユーティリティはブロック型デバイスを直接オープンして読み取りを実行するため,セキュリティ上の問題につながる可能性があります。 salvage ユーティリティを -S オプション付きで実行すると,現在の AdvFS ドメインからデータの復元を試みるときに,削除済みの古い AdvFS ドメインのデータも取り込まれる可能性があります。

次の例では,ドメイン PERSONNEL からデータをブロック単位で復元します。

# /sbin/advfs/salvage -S PERSONNEL
salvage: Domain to be recovered 'PERSONNEL'  
salvage: Volume(s) to be used '/dev/disk/dsk12c'
salvage: Files will be restored to '.'  
salvage: Logfile will be placed in './salvage.log'  
salvage: Starting sequential search of all volumes: 07-Oct-2001
salvage: Loading file names for all filesets: 07-Oct-2001
salvage: Starting recovery of all filesets: 07-Oct-2001

6.3    問題の修復

この節では,システムをリストアするさまざまな方法を説明します。

6.3.1    ドメイン・パニックからの回復

メタデータ書き込みエラーが発生するか,AdvFS ドメインの 1 つで破損が検出された場合,システムは,そのドメインに対してドメイン・パニック (システム・パニックではない) を発生させます。 これにより,障害の発生したドメインは隔離され,システムは他のすべてのドメインで正常に機能し続けます。 ドメイン・パニック後は,障害の発生したドメインのディスク・コントローラへの I/O 要求を AdvFS が発行することはありません。 障害の発生したドメインへのアクセスはできませんが,そのドメイン内のファイルセットのアンマウントは可能です。

ドメイン・パニックが発生すると,EVM イベントのログが記録され ( EVM(5) を参照),次のようなメッセージがシステム・ログおよびコンソールに出力されます。

AdvFS Domain Panic; Domain name Id domain_Id

例:

AdvFS Domain Panic; Domain staffb_domain Id 2dad7c28.0000dfbb
An AdvFS domain panic has occurred due to either a
 metadata write error or an internal inconsistency.
This domain is being rendered inaccessible.

特に設定しなければ,アクティブなドメインでドメイン・パニックが発生すると,ライブ・ダンプが生成され,/var/adm/crash ディレクトリに置かれます。 さらに,AdvFS 関連のエラーが /var/adm/binary.errlog に記録される場合もあります。

ドメイン・パニックから回復するには,次の手順を実行します。

  1. mount コマンドに -t advfs オプションを指定して実行し,影響を受けているドメイン内のファイルセットをすべて把握します。

  2. これらのファイルセットをすべてアンマウントします。

  3. システムの障害レポート情報を保存します (6.2.1 項)。

  4. ドメインのメタデータを保存します。 詳細については, savemeta(8) および 6.2.2 項を参照してください。

  5. 障害がハードウェアに起因するものである場合は,それを解決してから続けます。

  6. ドメイン上で /sbin/advfs/verify ユーティリティを実行します (6.2.4 項を参照)。

  7. 障害のために完全な回復が行えない場合は,新しいドメインを作成します(6.2.6 項)。

次の例では,ドメイン staffb_dmn 上のシステム・パニックの後で,必要な一連のコマンドを実行しています。

# mount -t advfs
staffb_dmn#staff3_fs on /usr/staff3 type advfs (rw)
staffb_dmn#staff4_fs on /usr/staff4 type advfs (rw) 
# umount /usr/staff3
# umount /usr/staff4
# sys_check -escalate
# /sbin/advfs/savemeta staffb_dmn /tmp/saved_dmn
# /sbin/advfs/savemeta -f staff3_fs /tmp/saved_staff3
# /sbin/advfs/savemeta -f staff4_fs /tmp/saved_staff4
# /sbin/advfs/verify staffb_dmn

ドメイン・パニックが発生しても,リブートする必要はありません。

ドメイン・パニック前に,I/O エラーを報告するメッセージが表示された場合,修復すべきハードウェア障害に起因する可能性があります。 次に,I/O エラー・メッセージの例を示します。

   AdvFS I/O error:
       Domain#Fileset: staffb_dmn#staff3_fs
       Mounted on: /usr/staff3
       Volume: /dev/disk/dsk6c
       Tag: 0x00000006.8001
       Page: 56
       Block: 1200
       Block count: 128
       Type of operation: Write
       Error: 19
       EEI: 0x6200 (Advfs cannot retry this)
       AdvFS initiated retries: 0
       Total AdvFS retries on this volume: 0
       I/O error appears to be due to a hardware problem.
       Check the binary error log for details.
       To obtain the name of the file on which
       the error occurred, type the command:
         /sbin/advfs/tag2name /usr/staff3/.tags/6

I/O エラーを示さないドメイン・パニックが繰り返し起こる場合,まず,fixfdmn ユーティリティを実行してみます (6.2.5 項)。 fixfdmn を実行してもドメイン・パニックが起こる場合,AdvfsDomainPanicLevel 属性 (5.15 節) を調整して,問題解決に役立つ情報を取得することもできます。

6.3.2    読み取り専用でマウントされたファイルセットの復旧

ファイルセットのマウント時に,AdvFS はドメイン内のすべてのボリュームにアクセスできることを確認します。 ドメインのメタデータに記録されているサイズは,各ボリュームでボリュームのサイズと一致しなければなりません。 サイズが一致すると,マウント処理が続行されます。 記録されているサイズよりも実際のボリュームが小さい場合,AdvFS は,ファイルセットで使用中とマークされている最後のブロックを読み込もうとします。 このブロックが読み込めればマウントは成功しますが,ファイルセットは読み取り専用になります。 使用中の最後のブロックが読み取れないボリュームがドメイン内にある場合,マウントは失敗します。 詳細については, mount(8)を参照してください。

ファイルセットが読み取り専用でマウントされている場合,エラー・メッセージにフラグ付きで示されたボリュームのラベルをチェックしてください。 よくあるエラーには,次の 2 つがあります。

AdvFS Utilities を利用でき,かつドメインが複数のボリュームで構成されており,さらに障害の発生したボリューム (フラグのついた) を削除できるだけの空きスペースがある場合,ファイルセットを削除する必要はありません。 ただし,次の作業に進む前に,バックアップを作成してください。

  1. rmvol コマンドを使って,ドメインからボリュームを削除します。 これにより,データは自動的に残りのボリュームに移されます。 残りのボリュームに十分な空きスペースがない場合は,ボリュームを削除する前に addvol コマンドを使用してスペースを追加します。

  2. disklabel コマンドを使って,障害のあるボリュームのディスク・ラベルを修復します。

  3. addvol コマンドを使って,修復したボリュームをドメインに戻します。

  4. balance コマンドを実行して,データを新しいボリュームに分散させます。

たとえば,ドメイン data5 内の /dev/disk/dsk2c (disk_aと呼ぶデバイスにあるとする) のラベルが正しくない場合,以下のコマンドで,そのボリューム上のファイルを移動し (rmvol コマンドで自動的に),ボリュームを修復しデータをリストアした後に,それらのファイルを元に戻すことができます。 最初の addvol のステップは,削除するボリューム上の情報のためにドメインのスペースが必要な場合のみ行ないます。

# addvol /dev/disk/dsk3c data5
# rmvol /dev/disk/dsk2c data5
# disklabel -z dsk2
# disklabel -rw dsk2 disk_a
# addvol /dev/disk/dsk2c data5
# balance data5

AdvFS Utilities を利用できない場合,次の手順を実行します。

  1. ドメイン内のすべてのファイルセットのバックアップを取ります。

  2. rmfdmn コマンドを使って,ドメインを削除します。

  3. disklabel コマンドを使って,ボリュームのディスク・ラベルを修復します。

  4. 新しいドメインを作成します。

  5. バックアップからファイルセットをリストアします。

たとえば,ドメイン data3 を含む /dev/disk/dsk1c (disk_a と呼ぶデバイスにあるとする) のラベルが正しくない場合,次のようにコマンドを実行します。

# vdump -0f -u /data3
# rmfdmn data3
# disklabel -z dsk1
# disklabel -rw dsk1 disk_a
# mkfdmn data3
# mkfset data3 data3fset
# mount data3#data3fset /data3
# vrestore -xf - /data3 

6.3.3    /etc/fdmns ディレクトリのリストア

ファイルセットをマウントするためには,AdvFS に有効な /etc/fdmns ディレクトリがなければなりません (2.3.1 項を参照)。 /etc/fdmns ディレクトリが間違っているか,または損傷していると,ドメインにアクセスできなくなりますが,ドメイン内のデータはそのまま残っています。 /etc/fdmns ディレクトリはバックアップからリストアするか,あるいは再作成することができます。

このディレクトリの最新状態のバックアップ・コピーがある場合には,バックアップから /etc/fdmns ディレクトリをリストアすることをお勧めします。 /etc/fdmns ディレクトリのバックアップには,標準のバックアップ機能 (vdumptar,または cpio) を使用できます。 ディレクトリをリストアするには,バックアップ・プロセスと互換性のある回復手順を使用します。

/etc/fdmns ディレクトリをリストアできない場合,このディレクトリは手作業または /sbin/advfs/advscan コマンドによって再構成できます。 手作業での再構成については 6.3.3.1 項/sbin/advfs/advscan コマンドによる再構成については 6.3.3.2 項をそれぞれ参照してください。 /etc/fdmns ディレクトリを再構成するための手順は,シングル・ボリュームとマルチボリュームのいずれのドメインの場合も類似しています。 失われているドメイン,失われているリンク,またはディレクトリ全体に関して,ディレクトリの再構成を行うことができます。

6.3.3.1    手作業による /etc/fdmns ディレクトリの再構成

ディレクトリを手作業で再構築する場合は,それぞれのドメイン名とその対応するボリュームを知っておく必要があります。

注意

既存のドメインを再構築するために mkfdmn コマンドを実行しないでください。 実行するとそのボリューム上のデータが破損します。 ファイルが破損した場合,salvage コマンドに -S オプションを指定して実行することで,一部のファイルを復旧できる場合があります。

次の例では,/etc/fdmns ディレクトリと 2 つのドメインを再構築します。 この例では,ドメインは存在してその名前も知っています。 各ドメインは,シングル・ボリューム (特殊デバイス) からなります。 リンクを作成する順序は問いません。 この 2 つのドメインは,/dev/disk/dsk1c 上の domain1 と,/dev/disk/dsk2c 上の domain2 です。

# mkdir /etc/fdmns
# mkdir /etc/fdmns/domain1
# cd /etc/fdmns/domain1
# ln -s /dev/disk/dsk1c .
# mkdir /etc/fdmns/domain2
# cd /etc/fdmns/domain2
# ln -s /dev/disk/dsk2c .

次の例では,1 つのマルチボリューム・ドメインを再構成しています。 domain1 ドメインは,3 つのボリューム /dev/disk/dsk1c/dev/disk/dsk2c,および /dev/disk/dsk3c を含みます。

# mkdir /etc/fdmns
# mkdir /etc/fdmns/domain1
# cd /etc/fdmns/domain1
# ln -s /dev/disk/dsk1c .
# ln -s /dev/disk/dsk2c .
# ln -s /dev/disk/dsk3c .

6.3.3.2    advscan コマンドによる /etc/fdmns ディレクトリの再構成

/sbin/advfs/advscan コマンドを使用すると,ディスクを新しいシステムに移動した場合,デバイス番号を変更した場合,またはドメインの位置が分らなくなった場合に,どのディスク・パーティションや,どの Logical Storage Manager (LSM) ボリュームが AdvFS のドメインの一部になっているかを確認することができます。 このコマンドはまた,間違えて /etc/fdmns ディレクトリを削除してしまった場合,/etc/fdmns ディレクトリからドメインを削除してしまった場合,または /etc/fdmns ディレクトリのドメインのサブディレクトリからのリンクを削除してしまった場合に,/etc/fdmns ディレクトリのすべてまたは一部を再構築する目的でも使用できます。 詳細については, advscan(8)を参照してください。

AdvFS ファイル・システムを正しく動作させるためには,各ドメインで,次の 3 つの数値が一致していなければなりません。

  1. advscan コマンドによって検索された,同一のドメイン ID を持つ物理パーティションの数。

  2. ドメインのボリューム・カウント。 AdvFS のディスク上のメタデータに記憶され,ドメイン内のパーティション数を示します。

  3. /etc/fdmns のパーティションへのリンク数。 各パーティションがリンクで表されるためです。

これらの数値が一致しない場合,advscan コマンドは,そのドメインを修正しようとします。

これらの数値が一致しなくなる原因はいくつかあります。 一般的にadvscan コマンドは,パーティション数や /etc/fdmns リンクの数よりもドメインのボリューム・カウントの方を信頼性が高いものとして扱っています。 以下の表では,不一致状態,考えられる原因,および advscan ユーティリティで実行できる修正処置の一覧を示します。

表 6-1 は,/etc/fdmns/domain_name ディレクトリ内のリンク数が,パーティション数とドメイン・ボリューム・カウントの予想値と一致しない場合の,考えられる原因と修正処置を示しています。

表 6-1:  リンク数の不一致

リンク数 考えられる原因 修正処置
少なすぎる addvol コマンドが早期に終了してしまった。 または /etc/fdmns/domain_name 内のリンクが手動で削除された。 advscan コマンドに -f オプションを指定して実行する前にドメインがアクティブ化されており,不一致の原因が addvol の中断によるものである場合,この状態は自動的に修正されます。 それ以外の場合には,advscan ユーティリティが,/etc/fdmns/domain_name ディレクトリにパーティションを追加します。
多すぎる rmvol コマンドが早期に終了してしまった。 または /etc/fdmns/domain_name 内のリンクが手動で追加された。 ドメインがアクティブ化されており,不一致の原因が rmvol の中断である場合,状況は自動的に修正されます。 /etc/fdmns/domain_name に手動で追加したリンクが原因であれば,/etc/fdmns/domain_name ディレクトリ内のリンクを体系的に削除し,ドメインをアクティブ化します。 削除するリンクの数は,/etc/fdmns/domain_name ディレクトリ内のリンク数から,advscan コマンドで表示されるドメイン・ボリューム・カウントを引いた数です。

表 6-2 は,ドメイン・ボリューム・カウントが,パーティション数と /etc/fdmns/domain_name ディレクトリ内のリンク数の予想値と一致しない場合の,考えられる原因と修正処置を示しています。

表 6-2:  ドメイン・ボリューム・カウントの不一致

ドメイン・ボリューム・カウント 考えられる原因 修正処置
少なすぎる 原因不明 修正できない。 /sbin/advfsfixfdmn コマンドを実行し,ドメインを使用可能な状態にします。
多すぎる addvol コマンドが早期に終了してしまった。 追加しようとしているパーティションが存在しない,あるいは再利用された。 修正できません。 salvage ユーティリティを実行し,ドメインに残っているボリュームからできるだけ多くのデータを復元します。

表 6-3 は,パーティション数が,ドメイン・ボリューム・カウントと /etc/fdmns/domain_name ディレクトリ内のリンク数の予想値と一致しない場合の,考えられる原因と修正処置を示しています。

表 6-3:  パーティション数の不一致

パーティション数 考えられる原因 修正処置
少なすぎる パーティションの消失 修復できません。 fixfdmn コマンドを使用してドメインを使用可能な状態にします。
多すぎる addvol コマンドが早期に異常終了した。 addvol コマンドを再度実行します。

次の例では,見つからなかったドメインはありません。 advscan コマンドはデバイス dsk0dsk5 を走査して,AdvFS パーティションを探し,2 つのパーティション,dsk0cdsk5c が見つかっています。 ドメイン・ボリューム・カウントとして,2 が報告され,2つのリンクが /etc/fdmns ディレクトリ内に登録されています。

# /sbin/advfs/advscan dsk0 dsk5
Scanning disks  dsk0 dsk5
Found domains:
usr_domain
                Domain Id       2e09be37.0002geb40
                Created         Thu Feb 28 09:54:15 2002
                Domain volumes          2
                /etc/fdmns links        2
                Actual partitions found:
                                        dsk0c
                                        dsk5c

次の例では,dsk6 を含むドメインを定義しているディレクトリが /etc/fdmns ディレクトリから削除されています。 このため,/etc/fdmns リンクの数,パーティションの数,およびドメインのボリューム・カウントが一致していません。 この例では advscan コマンドが,デバイス dsk6 を走査し,見つからないドメインを次のようにして再生しています。

  1. AdvFS ドメインを含むパーティションを見つけます。 ドメインのボリューム・カウントとして 1 を報告していますが,/etc/fdmns ディレクトリにはこのパーティションを含むドメイン・ディレクトリはありません。

  2. 別の AdvFS ドメインを含む別のパーティションを見つけます。 ドメインのボリューム・カウントは同様に 1 です。 このパーティションを含むドメイン・ディレクトリはありません。

  3. それ以外に AdvFS パーティションは見つかっていません。 ドメイン・ボリューム・カウントと見つかったパーティションの数は,検出されたどちらのドメインでも一致しています。

  4. advscan コマンドは,/etc/fdmns ディレクトリ内に,2 つのドメインのためのディレクトリを作成しています。

  5. advscan コマンドは,/etc/fdmns/domain_name ドメイン・ディレクトリ内にそれらのデバイスに対するシンボリック・リンクを作成しています。

/etc/fdmns ディレクトリにそのパーティションのディレクトリのエントリがない場合,そのパーティション名にはアスタリスク (*) がつけられ,ユーティリティによってそのドメイン名が作成されます。 復旧したドメインを元のドメインの名前に変更する必要があります。 この例では,元のドメインの名前は revenueexpenses です。

# /sbin/advfs/advscan -r dsk6
Scanning disks  dsk6
Found domains:
*unknown*
                Domain Id       2f2421ba.0008c1c0
                Created         Sun Jan 20 13:38:02 2002
 
                Domain volumes          1
                /etc/fdmns links        0
 
                Actual partitions found:
                                        dsk6a*
*unknown*
                Domain Id       2f535f8c.000b6860
                Created         Mon Feb 25 09:38:20 2002
 
               Domain volumes          1
                /etc/fdmns links       0
 
                Actual partitions found:
                                        dsk6b*

Creating /etc/fdmns/domain_dsk6a/
        linking dsk6a
 
Creating /etc/fdmns/domain_dsk6b/
        linking dsk6b
# mv /etc/fdmns/domain_dsk6a /etc/fdmns/revenue
# mv /etc/fdmns/domain_dsk6b /etc/fdmns/expenses

6.3.4    AdvFS ルート・ドメインのデータの損傷からの復旧

通常,AdvFS のルート・ドメインに回復不可能な損傷が生じた場合には,ルート・ファイル・システムを作り直して,システムをブート可能にする必要があります。 クラスタ構成を採用している場合は,『システム管理ガイド』および 『クラスタ管理ガイド』を参照してください。 また,ルート・ボリュームが LSM ボリュームの場合には,『Logical Storage Manager』を参照してください。 ルート・ドメインを再構築するには,root ユーザの特権が必要です。

インストレーション CD-ROM か,RIS (Remote Installation Service) サーバが必要です。 ルート・ドメインは,ブート・デバイス上に作成します。 ルート・ドメインの適切なバックアップがない場合は,損傷の性質と程度によっては,ルート・ファイルを/sbin/advfs/salvage ユーティリティで復旧できる場合があります。 詳細については,6.2.6 項 を参照してください。 salvage ユーティリティを使用して,最新のバックアップ後に修正または作成されたファイルを復旧できる場合もあります。

まず,ハードウェア・リソースを特定します。

  1. インストレーション CD-ROM からシステムをリブートする場合,SRM (System Reference Manual) コンソールのプロンプトに次のコマンドを入力し,CD-ROM デバイスの名前を調べます。

     >>> show device  
    ...
    DKA500        RRD47   1206   dka500.4.0.5.0
    ...
    

    この例では,CD-ROM デバイスの名前は DKA500 です。

    RIS サーバからブートする場合は,次のコマンドを入力してネットワーク・インタフェース・デバイスの名前を調べます。

    >>> show device | more
    ....
    ewa0.0.0.8.0    EWA0     08-00-2B-C3-E3-DC
    ...
    

    この例では,ネットワーク・インタフェース・デバイスの名前は EWA0 です。

  2. コンソール・ブート・デバイスの名前を調べます。 デフォルト・ブート・デバイスの場合,次のコマンドで調べることができます。

    >>> show bootdef_dev
    bootdef_dev      dkb400.4.0.5.1
    

    上記の例の dkb400.4.0.5.1 は,dkb400 がブート・デバイスであること,dk はデバイスが SCSI ディスクであること,b はデバイスが SCSI バス b に接続されていること,400 はデバイスの SCSI ターゲット ID が 4 で 論理ユニット番号 (LUN) が 00 であることを示しています。 そこで,この例では,バス/ターゲット/LUN は,1/4/00 です。

    デフォルト・ブート・デバイスでない場合は,show device コマンドを実行し,表示されるリストから特定します。

  3. システムをインストレーション CD-ROM または RIS サーバからブートします。 たとえば,特定した上記のデバイスを,CD-ROM を使ってブートする場合,次のコマンドを入力します。

    >>> boot dka500
    

    RIS サーバを使用する場合は,次のコマンドを入力します。

    >>> boot ewa0
    

  4. インストールを終了します。 VGA グラフィック・コンソールを利用している場合は,インストレーションの終了を選択するか,「Installation and Configuration Welcome」ダイアログ・ボックスの [File] メニューからシェル・ウィンドウを選択します。 シリアル・コンソール・ターミナルを使用している場合には,3) Exit Installation を選択します。

システム構成を確認したら,次の手順を実行します。

  1. インストール・メディアからブートしたときに,ルート・ドメインがマウント可能の場合には,インストール手順では,まずインストールしたルート・ドメインの既存のデバイス・データベースを読み取ろうとします。 ハードウェア・データベースの読み取りに失敗すると,エラー・メッセージが表示されます。 このような状況が発生した場合は,UNIX が割り当てたそのデバイス名を,適切なハードウェア・デバイス名に変換する必要があります。

    /sbin/hwmgr コマンドに -view devices オプションを指定することで,(前の手順で説明したように) 復旧するデバイスをそのバス/ターゲット/LUN 情報から調べ,バックアップに使用するディスクを特定し,テープ・デバイスがインストールされていることを確認します。

    # /sbin/hwmgr -view devices
    HWID: Device Name     Mfg Model         Location
    ------------------------------------------------------------
    38:/dev/disk/floppy0c    3.5in floppy     fdi0-unit-0    
    41:/dev/disk/dsk0c   DEC RZ1DB-CA (C) DEC bus-1-targ-4-lun-0
    42:/dev/disk/dsk1c   DEC RZ1CB-CA (C) DEC bus-1-targ-5-lun-0
    43:/dev/disk/dsk2c   DEC RZ1CB-CA (C) DEC bus-1-targ-6-lun-0
    44:/dev/disk/cdrom0  DEC RRD47    (C) DEC bus-0-targ-5-lun-0
    46:/dev/ntape/tape0  DEC TLZ10    (C) DEC bus-1-targ-4-lun-0     
     
    

    この例のハードウェア・データベースでは,バス/ターゲット/LUN が 1/4/00 のディスクが dsk0 として認識されています。 /dev/disk/dsk0a は,損傷のあるルート・ドメインを含むボリュームです。

    特定したデバイスが妥当かどうかは,hwmgr コマンドに -flash オプションを指定すれば視覚的に確認できます。 このコマンドを実行すると,指定したディスクのランプが 30 秒間にわたって点滅します。

    # /sbin/hwmgr -flash light -dsf /dev/disk/dsk0a
    

  2. この時点でテープ・デバイスをインストールする必要がある場合は,次のコマンドを入力します。

    # /sbin/dn_setup -install_tape 
    

  3. 有効なバックアップがある場合は,そこからリストアできます。 バックアップが古いものである場合は,そこからリストアした後, salvage コマンドに -d オプションを指定してその後の情報を復元します。 有効なバックアップがある場合は,ステップ 9 に進みます。 バックアップに関連したファイルを救済する必要がある場合は,ステップ 8 に進みます。

  4. 古いルート・ドメインをマウントします。

    # mount old_root_domain#root /var/mnt
    

    マウントに失敗した場合は,ステップ 7 に進みます。 バックアップを行なうことはできません。

  5. 可能ならバックアップを作成します。 第 4 章を参照してください。

  6. /sbin/advfs/verify コマンドに -a を指定して実行します (6.2.4 項を参照)。 このコマンドが成功してエラーが表示されない場合,ステップ 12 に進みます。

  7. /sbin/advfs/fixfdmn コマンドを実行します。 詳細については,6.2.5 項を参照してください。 成功した場合は,ステップ 12 に進みます。

  8. salvage コマンドを実行してファイルを復旧し,一時ファイルセットかテープにそれを保存します。 古いバックアップがある場合,salvage コマンドに -d を指定して実行します。 オプションを指定しないと,ドメイン全体を救済することになります。

    たとえば,ボリューム /dev/disk/dsk0a 上の壊れたルート・ドメインのファイルを,ローカルの未使用ディスク /dev/disk/dsk2c に復旧するには,次の手順を実行します。

    1. 復旧した情報を一時的に保管するドメインとファイルセットを作成し,ファイルセットをマウントします。

      # mkfdmn /dev/disk/dsk2c RECOVER
      # mkfset RECOVER recover_fset
      # mkdir /var/recover
      # mount RECOVER#recover_fset /var/recover
      

    2. salvage コマンドを実行します。 コマンドの対象のボリュームを指定するために,-V オプションを使用する必要があります。 古いバックアップとともに用いるファイルを救済している場合は,-d オプションを使用し,バックアップ後に変更になった情報のみを救済するようにします。

      この例では,root ドメインのファイルが抽出され,/recover にマウントされたファイルセットに保存されます。

      # /sbin/advfs/salvage -D /var/recover -V /dev/disk/dsk0a
      salvage: Volume(s) to be used '/dev/disk/dsk0a'
      salvage: Files will be restored to '/recover' 
      salvage: Logfile will be placed in './salvage.log' 
      salvage: Starting search of all filesets: 09-Dec-2001
      salvage: Loading file names for all filesets: 09-Dec-2001
      salvage: Starting recovery of all filesets: 09-Dec-2001 
       
      

    3. salvage.log ファイルを調べ,すべての必要なファイルを復旧できたことを確認します。 いったん次のステップで mkfdmn コマンドを実行すると,さらに情報を抽出するために salvage コマンドを実行することはできません。

  9. 新しいルート・ドメインとルート・ファイルセットを作成します。 このファイルセットを /var/mnt にマウントします。

    # mkfdmn -r /dev/disk/dsk0a root_domain
    Warning: /dev/disk/dsk0a is marked in use for AdvFS.
    If you continue with the operation you can
    possibly destroy existing data.
    CONTINUE? [y/n] y
    # mkfset root_domain root
    # mkdir /var/mnt
    # mount root_domain#root /var/mnt
    

  10. 有効なバックアップ・ソースがある場合,そこからファイルをリストアします。

     # vrestore -xf  /dev/tape/tape0 -D /var/mnt
    

  11. 救済したファイルがあれば,復旧先からルート・ドメインにコピーします。 そして復旧用のドメインを削除します。

    # cd /
    # cp -Rp /recover/root/* /var/mnt
    # umount /mnt /recover
    # rmfdmn RECOVER
    rmfdmn: remove domain RECOVER [y/n] y
    rmfdmn: domain RECOVER removed.
    

    ルート・ドメインがリストアされました。

  12. システムを停止しリブートします。

この手順が成功しない場合は,オペレーティング・システムを再インストールし,ファイルを再作成します。

6.3.5    ハードウェア障害からの回復

ハードウェア障害のために AdvFS に問題が発生することがあります。 たとえば,ファイル・システムへの書き込みが,ハードウェア障害によって失敗した場合,メタデータの損傷として現れることがあります。 ハードウェアの問題は,AdvFS ファイル・システム側では解決できません。

マルチボリューム・ドメインの 1 つのドメインに原因不明のエラーが発生した場合,次の手順の 1 つ以上を行ないます。

6.3.6    AdvFS ディスクの別のマシンへの移動

マシンに障害が発生した場合,AdvFS ドメインを含むディスクを AdvFS ソフトウェアが動作している他のコンピュータに移すことができます。 ディスクを新しいマシンに接続し,/etc/fdmns ディレクトリを変更して,移動したボリュームを新しいシステムが認識するようにします。 新しいシステムとの競合を回避するために,ディスクの SCSI ID を割り当て直す必要がある場合があります。 詳細については,ディスクの製造元が提供する指示書を参照してください。 この処理を実行するには,root ユーザでなければなりません。

DVN4 ドメインを,オペレーティング・システム・ソフトウェアの Version 4 が動作しているシステムに移動することはできません。 これを行なうとエラー・メッセージが生成されます (互換性については,6.4.6 項を参照)。 Version 4 が動作しているマシンの DVN3 ドメインを Version 5 が動作しているマシンに移動することはできます。 新しいオペレーティング・システムは,以前の OS で作成されたドメインを認識します。

注意

ボリュームを新しいマシンに移動するのに addvol コマンド や mkfdmn コマンドは使用しないでください。 このコマンドを実行すると,移動しようとしているディスク上のすべてのデータが削除されます。 すでにこのコマンドを実行してしまった場合は,6.2.6 項 を参照してください。

ドメインがどのパーティション上にあるか分らない場合は,新しいマシンにディスクを追加し,/sbin/advfs/advscan ユーティリティを実行すると,この情報を再作成できることがあります。 また,ディスクのラベルをチェックして,過去にどのパーティションが AdvFS パーティションとして作成されていたかを確認することもできます。 パーティションがどのドメインに含まれていたかをディスク・ラベルで確認することはできません。

次の例では,古いマシン上の 2 つのディスク,dsk3dsk4 にドメイン testing_domain が存在するものとします。 このドメインには,2 つのファイルセット,sample1sample2 が含まれています。 これらのファイルセットは,/sample1/sample2 にマウントされています。 移動するドメインにパーティション dsk3cdsk4adsk4b,および dsk4g があることが既に分かっているものとします。 この場合,ディスクは次の手順で移動します。

  1. ディスクの移動先となる稼働中のマシンをシャットダウンします。

  2. 異常のあるマシンから取り出したディスクを正常なマシンに取り付けます。

  3. システムをリブートします。 シングルユーザ・モードでリブートする必要はありません。

  4. この新しいディスク用に作成されたデバイス・ノードを確認します。

    # /sbin/hwmgr -show scsi -full
    

    Device Name 欄をチェックして,今追加したディスクの名前を確認します。 ディスク番号が最も大きいものが,それに相当します。

  5. 新しいディスク ID はこの例では,disk 7disk 8 です。 /etc/fdmns ディレクトリを,移動したドメインからのシンボリック・リンクを含むように変更します。

    # mkdir -p /etc/fdmns/testing_domain
    # cd /etc/fdmns/testing_domain
    # ln -s /dev/disk/dsk7c .
    # ln -s /dev/disk/dsk8a .
    # ln -s /dev/disk/dsk8b .
    # ln -s /dev/disk/dsk8g .
    # mkdir /sample1
    # mkdir /sample2
    

  6. /etc/fstab ファイルに,移動したファイルセットのマウント・ポイント情報を追加します。

    testing_domain#sample1 /sample1 advfs rw 1 0
    testing_domain#sample2 /sample2 advfs rw 1 0
    

  7. ボリュームをマウントします。

    # mount /sample1
    # mount /sample2
    

6.3.7    マルチボリューム usr ドメインのリストア

マルチボリューム /usr ファイル・システムをリストアするには,その前に usr_domain ドメインとそのすべてのボリュームを再構成する必要があります。 ただし,マルチボリューム・ドメインのリストアには License Management Facility (LMF) が必要です。 LMF によって,マルチボリューム・ドメインの作成に必要な addvol コマンドを含む AdvFS Utilities が制御されます。

最初に 1 つのボリュームを含む usr ドメインを作成して addvol コマンドをリストアします。 続いて LMF をリストアし,それを使用して addvol コマンドを有効化します。 以上の処理が完了すれば,usr ドメインにボリュームを追加して,マルチボリューム・ドメイン全体を復元できます。

LMF は 2 つのコンポーネント,すなわち /usr/sbin/lmf に格納されているユーティリティと /var/adm/lmf 内のデータベースから構成されています。 システムによっては /var/usr にリンクされており,これらのディレクトリがともに usr ファイルセットに位置している場合もあります。 そのような構成のシステムでは,addvol コマンドと LMF の 2 つのコンポーネントを usr ファイルセットにリストアします。 /usr ディレクトリと /var ディレクトリが usr_domain 内の異なるファイルセットに配置されているシステムでは,addvol コマンドと LMF ユーティリティを usr ファイルセット,LMF データベースを var ファイルセットにそれぞれリストアします。

次の例は,dsk1gdsk2cdsk3cの 3 つのボリュームで構成されるマルチボリューム・ドメイン usr_domain のリストア方法を示しています。 usr_domain ドメイン内のファイルセット usr 内には,/var ディレクトリと /usr ディレクトリがともに配置されています。 /usr/var のバックアップ・テープが存在します。 (バックアップ・テープを作成する必要がある場合は 第 4 章 を参照してください。) この手順では,ルート・ファイル・システムは既にリストアされているものとします。 ルート・ファイル・システムのリストア方法については,6.3.4 項を参照してください。

  1. ルート・ファイルセットを読み書き両用でマウントします。

    # mount -u /
    

  2. 古い usr_domain へのリンクを削除して,1 つ目のボリュームを使用して新しい usr_domain を作成します。

    # rm -rf /etc/fdmns/usr_domain
    # mkfdmn /dev/disk/dsk1g usr_domain
    

  3. /usr および /var ファイルセットを作成しマウントします。

    # mkfset usr_domain usr
    # mount -t advfs usr_domain#usr /usr
    

  4. /usr にソフト・リンクを作成します。 lmf コマンドは,このディレクトリでデータベースを探すようになります。

    # ln -s /var /usr/var
    

  5. /usr のバックアップ・テープをセットし,そこからリストアします。

    # cd /usr
    # vrestore -vi
    (/) add sbin/addvol 
    (/) add sbin/lmf
    (/) add var/adm/lmf
    (/) extract
    (/) quit
    

  6. ライセンス・データベースをリセットします。

    # /usr/sbin/lmf reset
    

  7. usr_domainにボリュームを追加します。

    # /usr/sbin/addvol /dev/disk/dsk2c usr_domain
    # /usr/sbin/addvol /dev/disk/dsk3c usr_domain
    

  8. /usr バックアップの完全なリストアを行います。

    # cd /usr
    # vrestore -xv
    

次の例も,dsk1gdsk2cdsk3cの 3 つのボリュームで構成されるマルチボリューム・ドメイン usr_domain のリストア方法を示しています。 この例では,/var ディレクトリと /usr ディレクトリは usr_domain ドメイン内の異なるファイルセットに配置されています。 /usr/var のバックアップ・テープが存在します。 (バックアップ・テープを作成する必要がある場合は 第 4 章 を参照してください。) この場合は,/var/usr のバックアップ・テープをともにマウントしなければなりません。 この手順では,ルート・ファイル・システムは既にリストアされているものとします。 ルート・ファイル・システムのリストア方法については,6.3.4 項を参照してください。

  1. ルート・ファイルセットを読み書き両用でマウントします。

    # mount -u /

  2. 古い usr_domain へのリンクを削除し,1 つ目のボリュームを使用して新しい usr_domain を作成します。

    # rm -rf /etc/fdmns/usr_domain
    # mkfdmn /dev/disk/dsk1g usr_domain
    

  3. /usr および /var ファイルセットを作成しマウントします。

    # mkfset usr_domain usr
    # mkfset usr_domain var
    # mount -t advfs usr_domain#usr /usr
    # mount -t advfs usr_domain#var /var
    

  4. /var バックアップ・テープをセットし,そこからリストアします。

    # cd /var
    # vrestore -vi
    (/) add adm/lmf
    (/) extract
    (/) quit
    

  5. /usr バックアップ・テープをセットし,そこからリストアします。

    # cd /usr
    # vrestore -vi
    (/) add sbin/addvol
    (/) add sbin/lmf
    (/) extract
    (/) quit
    

  6. ライセンス・データベースをリセットします。

    # /usr/sbin/lmf reset
    

  7. ボリュームを usr_domain に追加します。

    # /usr/sbin/addvol /dev/disk/dsk2c usr_domain
    # /usr/sbin/addvol /dev/disk/dsk3c usr_domain
    

  8. /usrバックアップの完全なリストアを行います。

    # cd /usr
    # vrestore -xv
    

  9. /var バックアップの完全なリストアを行います。

    # cd /var
    # vrestore -xv
    

6.3.8    mkfdmn コマンドまたは addvol コマンドの誤った使用からの復旧

mkfdmn および addvol コマンドは,AdvFS で使用するようにボリュームを初期化します。 そのボリュームがすでに他の AdvFS ドメインの一部である場合,このコマンドを使用するとそのボリュームに存在するドメインのメタデータを壊します。 すでに初期化したボリュームに対して,これらのコマンドを誤って使用した場合,salvage ユーティリティに -S オプションを使用することで,そのファイルの一部を回復することができる場合があります。 詳細については,6.2.6.3 項を参照してください。

mkfdmn または addvol コマンドを実行した後に実行したコマンドが多いほど,元のボリュームの内容にはその分だけ変更が加えられ,salvage コマンドで救済できる情報は少なくなります。 salvage コマンドを使用しても十分な情報が得られない場合,唯一の選択肢は,バックアップからデータをリストアすることです。

6.4    問題の予防

クラッシュ発生後に各ドメインがマウントされると,システムによって回復コードが自動的に実行されます。 このコードはトランザクション・ログ・ファイルを見て,システム・クラッシュ時に実行していたファイル・システム操作が完了したか,バックアップされたかをチェックします。 これにより,AdvFS メタデータは,クラッシュ後も一貫した状態を保つことができます。 クラッシュ発生時とは異なるオペレーティング・システムでファイル・システムを回復することはお勧めできません。

システム・クラッシュによってデータがダメージを受けた場合,5.5 節 を参照して,そのような問題が将来起きないようにするために,データをディスクに書き込む方法を改善してください。

6.4.1    未使用スペースとディスク使用状況のチェック

ディスク・スペースの割り当て状況は,ファイル,ファイルセット,またはドメイン別に確認できます。 表 6-4 は,ディスク・スペースの使用状況を調べるために使用できるコマンドを示しています。

表 6-4:  ディスク・スペースの使用状況に関するコマンド

コマンド 機能
df [脚注 2] [脚注 3] ディスク・スペースの使用状況をファイルセット別に表示します。 ファイルセットが使用できるスペースは,ファイルセット・クォータが設定されている場合,それによって制限されます。 ソフトとハードの両方のクォータが設定されている場合は,そのうちの小さい方のクォータ限界値を使って,利用できるディスク・スペースの値が計算されます。 ドメインに,指定したファイルセット・クォータで利用可能な値より少ないスペースしかない場合は,このコマンドは,そのドメインで実際に使用できるスペースの値を表示します。 複数のファイルセットを含み,ファイルセット・クォータを設定していないドメインの場合,すべてのファイルセットの容量の合計が 100% を超える場合があります。 各ファイルセットで使用可能なスペースはドメイン全体であるため,この計算で使われる利用可能なスペースの数値が,ドメインの全スペースになるためです。
du ファイルのブロック割り当てに関する情報を表示します。 -a オプションを指定すると,個々のファイルの情報が表示されます
ls ファイルごとにディスク・スペース使用量を表示します。 -l オプションを指定すると,スパース・ファイルの未割り当て部分も含めて,ディスク・スペースの大きさが表示されます。 -s オプションを指定すると,実際に割り当てられているブロック数が表示されます。 このオプションは,特にスパース・ファイルの占有領域を確認する手段として利用できます。
showfdmn [脚注 3] アクティブなドメイン内のそれぞれのボリュームの属性とブロック使用状況を表示します。 マルチボリューム・ドメインでは,その他のボリューム情報も表示されます。
showfile 特定のファイルの,またはディレクトリ内のファイルの,ブロック使用状況とボリューム情報を表示します。
showfsets [脚注 3] ドメイン内のファイルセットに関する情報を表示します。 -q オプションを指定すると,ファイルセット・クォータの限界値が表示されます。
vdf [脚注 2] [脚注 3] showfdmnshowfsets,およびdf コマンドの出力を再フォーマッティングします。 この 3 つのコマンドの機能は,vdf コマンドにもあてはまります。

df および showfsets コマンドでは,メタデータとクォータ・ファイルが使用するディスク・スペースを含みません。 そこで Used フィールドには,実際にドメインが使用している容量より小さい値が示されている可能性があります。 vdf コマンドでは,メタデータとクォータ・ファイルの情報を含むディスク使用量を表示します。 詳細については,3.4.2.4 項 とこのコマンドのリファレンス・ページを参照してください。

状況によっては,AdvFS のディスク使用状況の情報が破損することもあります。 この情報を修復するには,quotacheck コマンドに -v オプションを指定して実行します。

クォータのディスク使用量を調べるには,3.4 節を参照してください。

6.4.2    ボリュームの再利用

既存ドメイン (/etc/fdmns ディレクトリにエントリが存在する) のストレージを他のドメインに追加するには,rmvol コマンドを使ってそのドメインからボリュームを削除して,それを他のドメインに追加します。 AdvFS は自動的にドメインのディスク使用量を更新します。

たとえば,ドメイン old_domain 内のボリューム /dev/disk/dsk5c を,ドメイン new_domain に追加する場合には,old_domain 内のファイルセットをすべてマウントした後,次のコマンドを実行します。

# rmvol /dev/disk/dsk5c old_domain
# addvol /dev/disk/dsk5c new_domain

追加するディスクまたはディスク・パーティションが既存のドメインの一部でなくても,ラベルが設定されているために警告メッセージが表示される場合は,ディスク・ラベルをリセットします。 これを disklabel コマンドを使用せずに行なうことができます。 addvol または mkfdmn コマンドの実行時に表示されるプロンプトに yes と答えると,ディスク・ラベルがリセットされます。 この操作を行うと,追加するディスクまたはディスク・パーティション上のすべての情報が失われます。 ディスクを他のシステムで使用するために移動したい場合は,6.3.6 項を参照してください。

6.4.3    ディスク障害

データを定期的かつ頻繁にバックアップし,ディスク障害の兆候を見逃さないようにします。 障害が顕在化する前に,問題のあるディスクからファイルを削除することにより,多くのトラブルを未然に防ぐことができます。 AdvFS Utilities を利用している場合,addvol コマンドを使用して新しいディスクを追加し,rmvol コマンドを使用して問題のあるディスクを削除することができます。 ディスクの動作状況の確認方法についての詳細は,『システム管理ガイド』のイベント管理に関する情報を参照してください。

6.4.4    ディスク使用量の制御

リソースの使用についての制限が一切ない状態でシステムが稼働している場合は,システムにクォータを追加して,ユーザがアクセスできるディスク・スペースの容量を制限することができます。 ユーザ・クォータおよびグループ・クォータは,UFS のクォータと同様に,ユーザまたはグループが 1 つのファイルセットに対して割り当てることができるスペースの量を制限します。 ファイルセット・クォータは,AdvFS で導入されたもので,ドメインで利用できるすべてのスペースを 1 つのファイルセットで使い切ってしまうのを防ぎます。 詳細については,第 3 章を参照してください。

6.4.5    クォータ限界値と猶予期間の上限の設定

クォータ限界値に達しつつある場合,または限界値に達するとは思えない場合でも,クォータ・システムの限界値を超過する可能性があります。 クォータに関する詳細は 第 3 章 を参照してください。

6.4.5.1    クォータ限界値の超過

エディタの使用中に,編集データを保存するとクォータの限界値を超えることが分かった場合,エディタを強制終了したりファイルに書き出すとデータが失われる可能性があります。 その代わり,次のいずれかを行ないます。

6.4.5.2    クォータ限界値までの保存

ハードおよびソフト限界値は,その値自体を含みません。 その値未満の場合だけ,ファイルを作成することができます。 たとえば,ハード限界値が1000 ファイルの場合,作成できるのは 999 ファイルまでです。

ブロック数のハードおよびソフト限界値も同様に,その値自体を含みません。 AdvFS ではまれに,ユーザ,グループ,またはファイルセット・クォータ値に達するまでに残り 8K バイトとなった時点で,残りのスペースの一部または全部を使用しようとすると,クォータに制約される場合があります。 これは,AdvFS がストレージを 8K バイト単位で割り当てるためです。 ファイルに 8K バイトのデータを追加するとクォータの限界値に達するか超えてしまう場合,そのファイルは拡張されません。

6.4.5.3    クォータ限界値の変更

マウントしていないか,または /etc/fstab ファイル (2.4.1 項) に userquotagroupquota オプションが設定されていないファイルセットに対して,クォータ限界値または猶予期間を設定しても,設定した値は保持されません。 edquota コマンドを実行する前に,/etc/fstab のエントリをアップデートし,ファイルセットをマウントする必要があります。

6.4.5.4    猶予期間の無効化

猶予期間を無効にするには,edquota コマンドで値を 1 秒に設定します。 値を 0 日に設定すると,省略値の猶予期間の7 日が適用されます。

6.4.6    ディスク構造の互換性の問題の回避

Version 5.0 以降のオペレーティング・システムで作成されるドメインは,以前のバージョンとは互換性のない新しいオンディスク・フォーマットになります (2.3.3 項を参照)。 新しいオペレーティング・システムは以前のディスク構造を認識しますが,以前のオペレーティング・システムは新しいディスク構造を認識しません。 Version 5.0 以降のオペレーティング・システムのフル・インストレーションを行う代わりに,Version 4 からのアップデート・インストレーションを行う場合,/root/usr,および /var のファイルは,DVN が 3 のままになります。 一方,Version 5.0 のフル・インストレーションを行う場合には,これらの各ディレクトリに含まれるファイルの DVN は 4 になります。

旧バージョンのオペレーティング・システムから DVN4 のファイルセットにアクセスするには,Version 5.0 以降のオペレーティング・システム・ソフトウェアが稼働しているサーバからファイルセットを NFS マウントします。 Version 5.0 より前のバージョンのオペレーティング・システムが稼働している環境で,DVN4 のドメインに属するファイルセットをマウントしようとすると,エラー・メッセージが表示されます。

DVN3 のドメインを DVN4 に自動的にアップグレードするツールはありません。 ドメインを DVN4 にアップグレードするには,2.3.3.4 項の手順に従ってください。

6.4.7    ユーティリティの互換性の問題の回避

Version 5.0 以降のオペレーティング・システムで作成されるドメインは,新しいオンディスク・ファイル・フォーマットになっているため,以前のリリースの AdvFS Utilities の中には,使用すると DVN4 ドメインを壊す可能性があるものがあります。 旧バージョンのオペレーティング・システムの,静的にリンクされた AdvFS 固有のユーティリティは,Version 5.0 以降では動作しません。 このようなユーティリティは,通常 Version 4.0 より前のオペレーティング・システムのユーティリティです。 また,旧バージョンの Tru64 UNIX に含まれる,以下に示す動的にリンクされた AdvFS Utilities は,Version 5.0 以降では動作しません。

6.4.8    ログ・ファイルの不整合の回避

システムがクラッシュすると,AdvFS はリブート時に復旧しようとします。 クラッシュ時にマウントされていたファイルセットのあるドメインは,そのドメインのファイルセットを再マウントすると回復します。 この回復処理では,AdvFS トランザクション・ログ・ファイルを使用して,AdvFS メタデータの一貫性を保ちます。

オペレーティング・システムのバージョンによってトランザクション・ログ・ファイルの構造は異なります。 そのため,AdvFS の回復操作は,クラッシュ時に使用していたオペレーティング・システムと同じバージョンで実行することが重要です。 そうしないと,ドメイン・メタデータの破壊やドメイン・パニック (あるいはその両方) が発生する危険性があります。

AdvfsDomainPanicLevel 属性 (5.7 節を参照) で,ドメイン・パニックをシステム・パニックに発展させるように設定したためにシステム・クラッシュが発生した場合,パニックが発生したドメインで /sbin/advfs/verify コマンドを実行して,データが損傷していないことを確認します。 クラッシュ時にファイルセットがアンマウントされていた場合,または再マウントを実行し,verify コマンドを実行した場合,そのファイルセットを,適切であれば,異なるバージョンのオペレーティング・システムにマウントすることができます。

6.4.9    AdvFS ルート・ドメインのサイズ拡張

AdvFS のルート・ドメインを置くことができるボリューム (パーティション) の数は,クラスタ構成の場合を除いて 1 つだけです。 したがって,ルート・ドメインのサイズを拡張するには,ルート・ドメインを含むボリュームのサイズを増やすか,より大きなボリューム上にルート・ドメインを作り直す必要があります。

6.4.9.1    ルート・ボリュームのサイズ拡張

ルート・ドメインを含むボリュームのサイズを拡張した場合,2.3.4.3 項 の手順に従って,mount コマンドに -o extend オプションを指定して,システムにそれを知らせる必要があります。 ルート・ボリュームが,LSM ボリュームの場合は,『Logical Storage Manager』を参照してください。

6.4.9.2    ルート・ボリュームの大きなデバイスへの移動

ルート・ドメインを別のデバイスに再作成するには,インストールした新しいデバイスと,インストレーション CD-ROM または RIS サーバ,およびドメインをバックアップするためのバックアップ・テープまたは未使用のディスク・パーティションが必要です。

ルート・ドメインを移動するには,まず新しいディスクをインストールし,それを認識させる必要があります。 ルート・ボリュームに使用するディスクがすでにインストールされている場合は,ステップ 5 を省略し,次に進みます。

  1. システムをシャットダウンします。

  2. 新しいディスク・デバイスをインストールします。 この方法については,ハードウェア・マニュアルを参照してください。

  3. 追加したディスクがコンソールで認識されることを確認します。 次の例では,DKB300 が追加されています。

    >>> show device
    polling ncr0(NCR 53C810) slot 1, bus 0 PCI, 
         hose 1 A SCSI Bus ID 7
    dka500.5.0.1.1     DKA500                   RRD45     1645
    polling isp0(QLogic ISP1020) slot 4, bus 0 PCI, 
         hose 1 SCSI Bus ID 7
    dkb0.0.0.4.1       DKB0                     RZ1DB-CA  LYJ0
    dkb100.1.0.4.1     DKB100                   RZ1CB-CA  LYJ0
    dkb200.2.0.4.1     DKB200                   RZ1CB-CA  LYJ0
    dkb300.3.0.4.1     DKB300                   RZ1BB-CS  0656 
    mkb400.4.0.4.1     MKB400                   TLZ10     02ab
    ...  
    

  4. システムをリブートします。 ブート中にオペレーティング・システムが新しいデバイスを認識し,それをデバイス情報データベースに適宜反映します。 追加したディスクには,オペレーティング・システムによって dsk6 というデバイス名が付けられているとします。

    特定したデバイスが妥当かどうかは,/sbin/hwmgr コマンドに -flash オプションを指定すれば視覚的に確認できます。 このコマンドを実行すると,指定したディスクのランプが 30 秒間にわたって点滅します。

    # /sbin/hwmgr -flash light -dsf /dev/disk/dsk6a
    

  5. root としてログインし,/etc/fdmns ディレクトリでルート・ドメインを含むボリュームを調べます。

    # ls -l /etc/fdmns/root_domain
    total 0
    lrwxrwxrwx   1 root     system 15 Feb 1 2002 dsk3a -> /dev/disk/dsk3a
    

    この例では /dev/disk/dsk3a がルート・ドメインを含むボリュームです。

  6. 必要に応じ disklabel コマンドに -t advfs オプションを指定して,または diskconfig ユーティリティを使用して (Boot Block: リストから AdvFS を選択),新しいディスクを AdvFS のブート可能ディスクとして構成します。 この作業には root 権限が必要です。

    # disklabel -r dsk6 > /tmp/backupdisklabel
    # disklabel -R -r -t advfs dsk6 /tmp/backupdisklabel
    # rm /tmp/backupdisklabel
     
    

  7. 新しいデバイスにルート・ドメインを作成します。

    1. 古いルート・ドメインからブートしたシステムをシャットダウンします。

    2. オペレーティング・システム CD-ROM または RIS サーバからブートします。 たとえば CD-ROM を使用する場合,次のコマンドを入力します。

      >>> boot dka500
      

      たとえば RIS サーバを使用する場合,次のコマンドを入力します。

      >>> boot ewa0
      

    3. インストールを終了します。 VGA グラフィック・コンソールを使用している場合は,インストレーションの終了を選択するか,「Installation and Configuration Welcome」ダイアログ・ボックスの [File] メニューからシェル・ウィンドウを選択します。 シリアル・コンソール・ターミナルを使用している場合には,3) Exit Installation を選択します。

    4. 新しいルート・デバイスに新しいルート・ドメインとルート・ファイルセットを作成します。 元のデバイスにリンクするために /etc/fdmns ディレクトリに新しいエントリを作成します。

      # mkfdmn -r /dev/disk/dsk6a root_domain
      # mkfset root_domain root
      # mkdir /var/new_root
      # mount root_domain#root /var/new_root
      # mkdir /etc/fdmns/orig_root
      # ln -s /dev/disk/dsk3a /etc/fdmns/orig_root
      # mount orig_root#root /var/orig_root
       
      

    5. 古いルート・ドメインからファイルをダンプし,新しいルート・ドメインにリストアします。

      # vdump -0f - /var/orig_root | vrestore -xf \
        -D /var/new_root
       
      

  8. システム情報を新しいルート・ボリュームを指すようにアップデートします。 この例では,ルート・ドメインとスワップ・パーティションは dsk3 から dsk6 に移されています。 他に変更はありません。

    /etc/fdmns ディレクトリを,新しいルート・ドメインを認識するようにアップデートします。 ここでは,dsk6a が新しいルート・ドメインを含むボリュームであり,dsk3a が元のルート・ドメインを含むボリュームです。

    # cd /var/new_root/etc/fdmns/root_domain
    # ln -s /dev/disk/dsk6a dsk6a
    # rm dsk3a 
    

  9. システムを停止し,省略時のブート・デバイスを変更します。

    # halt
    . . . 
    >>> set bootdef_dev dkb300  
     
    

  10. 新しいルート・ドメインをブートします。

    >>> boot 
     
    

6.4.10    メモリ・マッピング,ダイレクト I/O,およびデータ・ロギングの互換性の問題

mount コマンドに -o adl オプションを指定して実行し一時的アトミック書き込みデータ・ロギングを有効にした場合を除き,メモリ・マッピング,アトミック書き込みデータ・ロギング,およびダイレクト I/O は相互に排他的です。 ファイルがこれらのモードのいずれかでオープンされている場合,同じファイルを競合するモードでオープンしようとすると失敗します。 詳細については,5.5 節5.6 節,および mmap(2) を参照してください。

メモリ・マッピング・モードのファイルは,smoothsync でフラッシュされますが,smoothsync_age によりフラッシュしない場合もあります。 これは,ファイルがマッピング解除された後で一時的にメモリ・マッピング・モードにとどまることがあることを意味します。 詳細については,『システムの構成とチューニング』 を参照してください。

6.4.11    古いデータへのアクセスの禁止

ディスク上の古くなったデータは削除しない限り,クラッシュの後,または salvage コマンドを実行した後に復旧することができます。 これらのデータがアクセスされないようにするには,chfsets コマンドを -o objectsafety オプションを指定して実行します。 オブジェクト・セーフティを選択すると,アプリケーションは古いデータにアクセスできなくなりますが,データが完全に破壊されるわけではありません。

オブジェクト・セーフティ・オプションを有効にすると,そのファイルセットに属するディスク上のページがゼロで充填され,ファイルによって使用される前にディスクに強制的に書き込まれます。 これにより,そのファイルの書き込み中にシステムがクラッシュしても,古いデータが見えてしまうことはなくなります。 オブジェクト・セーフティを有効にする直前にストレージを割り当てられたファイルでは,その割り当てに関連するバッファがディスクに書き込みされると,オブジェクト・セーフティが起動します。

たとえば,xyz_domain のファイルセット xyz3 のオブジェクト・セーフティを有効にするには,次のコマンドを入力します。

# chfsets -o objectsafety xyz_domain xyz3

オブジェクト・セーフティを使用すると,ページを 2 度ディスクに書き込まなければならないため性能は低下します。

6.4.12    無効または破損したセーブセット・フォーマット

ディスクに書き込まれたセーブセットのリストア時に,フォーマットが無効であるか,または壊れていることを示すメッセージが表示された場合には,そのセーブセットがパーティション a またはパーティション c にバックアップされていないかを確認してください。 これらのパーティションにはブロック 0 が含まれています。 ブロック 0 はディスク・ラベル・ブロックであり,不慮の書き込みから保護されています。 そこで,これらのパーティションにセーブセットをバックアップしようとしても,適切に保存されません。

ディスクのブロック 0 から始まるパーティションにセーブセットを正しくダンプするには,あらかじめディスク・ラベルをクリアする必要があります。 ディスク・ラベルをクリアしないで vdump コマンドを実行した場合でも,コマンド出力では有効なセーブセットが含まれているように見えます。 ところが,vrestore コマンドを実行すると,セーブセットに含まれるディスク・ラベルをセーブセットとして解釈したときに,エラーが返されます。 ディスク・パーティションへのダンプについては,4.3.7 項 を参照してください。

6.4.13    性能低下の対策

ディスクの性能は,それへの I/O 要求に依存します。 1 つのボリュームに高負荷のアクセスが集中するようにドメインが構築されている場合,システムの性能が低下します。 マルチボリューム・ドメインがある場合,さまざまな方法で負荷のバランスを改善し,スループットを向上させることができます。 詳細については,『システムの構成とチューニング』,および第 5 章を参照してください。

性能を低下させている原因を見つけるには,まずシステムの動作をチェックします。 性能を改善する方法は,数多くあります。

AdvFS Utilities を使用できる場合には,以下の作業を行うこともできます。

6.4.14    rmvol または migrate コマンドを起動できない

rmvol コマンド (2.3.5 項) を使用してボリュームの削除を実行し,そのコマンドが異常終了すると,まれにボリュームがアクセスできない状態になり,書き込みができなることがあります。 これらのボリュームには,showfdmn コマンドの出力結果に,"data unavailable" というマークがつきます。 この場合,chvolコマンドに -A オプションを指定して実行し,ボリュームを再度アクティブ化します。